Hi Willy, On 09/08/2024 11:32, Willy Tarreau wrote: > Hi Björn, > > I'm coming back to this: > > 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 ;) > 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 :) Cheers, Matt -- Sponsored by the NGI0 Core fund.
