Hi Junio, On 21/05/2025 00:02, Junio C Hamano wrote: > Matthieu Baerts <matttbe@xxxxxxxxxx> writes: > >> Sorry, I was not clear. I meant "introducing MPTCP in the Linux kernel >> couldn't impact other protocols in terms of memory allocated per socket >> buffer or performances by adding extra checks a bit everywhere for example". > > Ah, OK. What you meant is that the networking maintainers did not > allow you to affect the "normal" codepath when adding MPTCP support > to their subsystem. Yes, that's what I meant to say, but you better said it :) > Which is conservative and probably a good thing, I guess. > > But that choice means each and every application need to opt-in, > which is cumbersome, inconvenient, and hampers adoption X-<. Indeed... But it looks like it is often the case with new protocols and extensions... >> listening socket supporting MPTCP on the server side will return a >> "plain" TCP socket to the userspace during the accept() call. That's why >> we recommend enabling MPTCP on the server side by default if supported: >> the impact is minimal, and MPTCP is only used when requested by the >> clients -- which are usually the ones benefiting more from MPTCP >> features. That's in fact the current behaviour for apps written in Go: >> MPTCP is now enabled by default on the server side, and it is easy to >> enable it on the client side when needed. > > That reminds me about one thing I forgot to ask. > > The git:// protocol is the only one we have control over what to ask > to the socket() system call and the posted patch was about the > client side [*]. > > On the other end of the connection, even though you could use the > dedicatd "git daemon" process sitting and listening on a socket, my > understanding is it is more common to spawn it via inetd(8). Does > it mean that the host needs to run inetd with MPTCP enabled? I do > not know how common that is. Good point. Indeed, for the server side, someone should then also look at inetd. I don't know how Muhammad's servers are deployed on his side.
