On Fri, Mar 25, 2016 at 9:53 AM, Willy Tarreau wrote: > > On Thu, Mar 24, 2016 at 11:49:41PM -0700, Eric Dumazet wrote: >> Everything is possible, but do not complain because BPF went in the >> kernel before your changes. > > Don't get me wrong, I'm not complaining, I'm more asking for help to > try to elaborate the alternate solution. I understood well what my > proposal did because it was pretty straightforward, and the new one > I'll have to do is of an immense complexity for me by now, since it > will require learning a new language and finding doc on how all this > works together. But as I said I'm totally sold to the benefits it can > provide for large scale deployments and I'm well aware of the ugly > socket scan there was in the previous one.
+1 (all the work done on the listeners, including SO_REUSEPORT, and until lately very much appreciated in any case!) > > If you could share a pointer to some good starter documentation for this, > I would appreciate it. I really have no idea where to start from and the > only elements I found on the net didn't give a single hint regarding all > this :-/ +1 On Fri, Mar 25, 2016 at 1:24 AM, David Miller wrote: > > If we encapsulate this into libraries and helper wrappers, there is > no reason web server developers should be looking at these details > anyways. ++1 > > Please don't make a mountain out of a mole-hill. Not my intention, you guys know what's the better for the kernel and its APIs. My concern is (was) admittedly due to my own lack of knowledge of (e)BPF, hence how much of kernel internals I'd need to know to make the SO_REUSEPORT work in my case. But sure, any of the help suggested above would make it go away, I'll stay tuned.
