io_uring behaviour with multiple threads

[anandv1223]

Hi,

Based on the review of some discussions here, for multithreaded applications , the general recommendation seems to be to have 1 ring per thread. I had a basic query is this regard. If all the threads are writing to the same interface fd (assume multicore cpu's), does the application have to take a lock(spinlocks) to protect the parallel writes or does the kernel ring/io management take care of write consistency?

Assuming we have a multithreaded application such that all threads process network packets from outside world ingressing via physical NIC's into the system and forward them out of the above interface (write to same tap fd using 1 io_uring per thread) to a different consumer process on the linux host listening on the tap ip. Will the input packet sequence be retained in the output stream in this case or there could be random interleaving depending on how the kernel processed the ring on each thread? Will the behaviour be identical to the scenario where a write syscall were used instead of io_uring?

[isilence]

First of all, there is no ordering guarantee between requests by default. It has nothing to do with the number threads, they will get reordered even for a single threaded app, look through #1282, I explained it a bit more there.

As for multithreaded apps, there is just one of each ring (completion, submission) for every io_uring instance. You'd need some protection to avoid writing to / reading from the rings in parallel, just how you'd do it with any other shared chunk of memory.