Hi Matthieu, On Fri, Aug 09, 2024 at 12:52:04PM +0200, Matthieu Baerts wrote: > On 09/08/2024 11:32, Willy Tarreau wrote: > > On Mon, May 06, 2024 at 02:10:02PM +0200, Björn Jacke wrote: > >> Hi, > >> > >> I came up a while ago with a patchset for MPTCP support for HAProxy also, > >> see https://github.com/haproxy/haproxy/issues/1028 > >> > >> Back then I also discussed some ideas with Willy how to implement it more > >> elegantly in HAProxy. It's still somewhere on my todo list but > >> unfortunately > >> I didn't catch that up since then. As I had a good real-world usecase > >> recently for MPTCP I though of looking into this again also. > > > > I had a look at this series, and am seeing that the largest part of the > > changes is to use ->sock_prot (either IPPROTO_TCP or IPPROTO_MPTCP) in > > getsockopt() and setsockopt() calls, which is not in Dorian's patchset. > > > > Thus I'm just wondering if this is mandatory or if there's a compatibility > > mode in the kernel so that IPPROTO_TCP also works for MPTCP sockets. Maybe > > Matthieu knows better and could enlighten us on this ? > > There is no need to change anything in the getsockopt() and setsockopt() > calls: it is still possible to use SOL_TCP (== IPPROTO_TCP). The kernel > will try to adapt the socket option to the MPTCP case, e.g. applying > something on all the subflows, or just the first one, or the MPTCP > socket, depending on the option. > > There are some socket options under SOL_MPTCP (284), but there are > "new", and specific to MPTCP, e.g. to get info about the different paths > being used, etc. > > If you replace IPPROTO_TCP in the getsockopt() and setsockopt() calls by > IPPROTO_MPTCP (262), it means you try to look at socket options with the > SOL_X25 level, that's not what we want here ;)
OK, thank you for the very detailed explanation! > > Because if it's required, we definitely need to apply similar changes > > everywhere (the code has probably evolved a little bit since 2021), and > > if not, it could mean that only the part that performs the protocol > > registration (that Matthieu+Dorian also handled) and the doc should > > suffice. I think we have everything in shape now to decide what's left > > to do in order to get the feature merged. I hope this time we won't > > miss the deadline! > > In theory, the last patch I sent should be enough. > > BTW, thank you for your other reply, no issues for the delay. I will try > to look at the modifications you requested when I can find some time :) That works for me. We'll release by end of november, with a hard freeze around a month earlier, so there's no rush, though it always helps to get feedback from users, of course! If you'd figure that you can't find the time to complete it in a reasonable delay, do not hesitate to ping me again about it to let me know, we'll find how to arrange this together. Also, I think it would be kind to leave a mention about Björn's work in your commit message, who attempted the very first implementation 3-4 years ago when haproxy's internals were probably less ready to deal with this, causing his work to be left pending for a while. Thanks! Willy
