On Mon, 2016-03-28 at 11:44 -0700, Rick Jones wrote: > On 03/28/2016 10:00 AM, Eric Dumazet wrote: > > On Mon, 2016-03-28 at 09:15 -0700, Rick Jones wrote: > >> On 03/25/2016 03:29 PM, Eric Dumazet wrote: > >>> UDP sockets are not short lived in the high usage case, so the added > >>> cost of call_rcu() should not be a concern. > >> > >> Even a busy DNS resolver? > > > > If you mean that a busy DNS resolver spends _most_ of its time doing : > > > > fd = socket() > > bind(fd port=0) > > < send and receive one frame > > > close(fd) > > Yes. Although it has been a long time, I thought that say the likes of > a caching named in the middle between hosts and the rest of the DNS > would behave that way as it was looking-up names on behalf those who > asked it.
I really doubt a modern program would dynamically allocate one UDP port for every in-flight request, as it would limit them to number of ephemeral ports concurrent requests (~30000 assuming the process can get them all on the host) Managing a pool would be more efficient (The 1.3 usec penalty becomes more like 4 usec in multi threaded programs) Sure, you always can find badly written programs, but they already hit scalability issues anyway. UDP refcounting cost about 2 cache line misses per packet in stress situations, this really has to go, so that well written programs can get full speed.
