RE: epoll_wait() performance
From: David Laight <hidden>
Date: 2019-11-28 10:17:40
Also in:
lkml
From: Eric Dumazet
Sent: 27 November 2019 17:47
...
A QUIC server handles hundred of thousands of ' UDP flows' all using only one UDP socket per cpu. This is really the only way to scale, and does not need kernel changes to efficiently organize millions of UDP sockets (huge memory footprint even if we get right how we manage them) Given that UDP has no state, there is really no point trying to have one UDP socket per flow, and having to deal with epoll()/poll() overhead.
How can you do that when all the UDP flows have different destination port numbers? These are message flows not idempotent requests. I don't really want to collect the packets before they've been processed by IP. I could write a driver that uses kernel udp sockets to generate a single message queue than can be efficiently processed from userspace - but it is a faff compiling it for the systems kernel version. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)