Re: Reimplementing ASIOs

From: Virgilio Fornazin (virgiliofornazin_at_[hidden])
Date: 2024-07-18 23:27:45

The linux kernel code for sendmmsg/recvmmsg is just a for loop, the cost of
syscall traversing ring3 to ring0(1 on virtualized) it's something that
really pays off in high performance udp networking.
If you consider something like this, thils would be a high win for high
packet I/O use in UDP.

On Thu, Jul 18, 2024 at 6:53 PM Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> On 18/07/2024 22:34, Virgilio Fornazin via Boost wrote:
> > a good point is to support sendmmsg / recvmmsg on linux/bsd (macos
> similar
> > syscall SYS_sendmsg_x / SYS_recvmsg_x)
> > to get good UDP throughput support.
> >
> > I didn't find io_uring support for sendmmsg/recvmmsg at that time, maybe
> a
> > time you could get coding / pushing this too.
>
> I believe the mm-variants of send and receive take a very different code
> path to what io_uring uses, so it will never support those.
>
> It's a bit like the other zero copy i/o path in Linux, it uses a weird
> code path to work and io_uring won't support it, ever. So they're
> forging ahead with their own zero copy approach which I believe requires
> NIC driver support, otherwise you get silent memory copying.
>
> I haven't personally tested it, but the multishot receive feature of
> io_uring should get quite close to recvmmsg performance.
>
> In any case, the once class leading UDP performance in Windows RIO Linux
> is steadily closing the gap. I believe FreeBSD still holds the record
> for the most packets switched per core per second, and that probably
> matters more for real world performance.
>
> Niall
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>