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. 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-<. > 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. Thanks. [Footnote] * On the public Internet, hopefully nobody is using that protocol anymore, and instead using either https:// or ssh:// that gives better integrity assurances.
