On Fri, Dec 9, 2016 at 8:53 AM, Eric Dumazet <[email protected]> wrote: > On Fri, 2016-12-09 at 08:43 -0800, Tom Herbert wrote: >> >> > > >> Are you thinking of allowing unconnected socket to have multiple input >> queues? Sort of an automatic and transparent SO_REUSEPORT... > > It all depends if the user application is using a single thread or > multiple threads to drain the queue. > If they're using multiple threads hopefully there's no reason they can't use SO_REUSEPORT. Since we should always assume DDOS is possibility it seems like that should be a general recommendation: If you have multiple threads listening on a port use SO_REUSEPORT.
> Since we used to grab socket lock in udp_recvmsg(), I guess nobody uses > multiple threads to read packets from a single socket. > That's the hope! So the problem at hand is multiple producer CPUs and one consumer CPU. > So heavy users must use SO_REUSEPORT already, not sure what we would > gain trying to go to a single socket, with the complexity of mem > charging. > I think you're making a good point a the possibility that any unconnected UDP socket could be subject to an attack, so any use of unconnected UDP has the potential to become a "heavy user" (in fact we've seen bring down whole networks before in production). Therefore the single thread reader case is relevant to consider. Tom > >> > >
