Hi Eric, 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. > Just rework your patch. > > Supporting multiple SO_REUSEPORT groups on the same port should not be > too hard really. Making sure BPF still work for them is feasible. > > But the semantic of the socket option would be really different. I don't care much about the socket options themselves as long as I can continue to support seamless reloads. I could even get rid of SO_REUSEPORT on Linux to use something else instead if I have a reliable way to detect that the alternative will work. > You need to not control an individual listener, but a group of listener. > > Your dying haproxy would issue a single system call to tell the kernel : > My SO_REUSEPORT group should not accept new SYN packets, so that the new > haproxy can setup a working new SO_REUSEPORT group. Normally it's the other way around :-) The new process first grabs the socket, there's a tiny window where both are attached, and only then the old process leaves. That's the only way to ensure there's no loss nor added latency in the processing. 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 :-/ Thanks, Willy
