From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Muhammad Nuzaihan <zaihan@unrealasia.net>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org
Subject: Re: Small patch to add support for MPTCP on Linux
Date: Mon, 19 May 2025 16:49:00 -0700 [thread overview]
Message-ID: <xmqqo6vokvpv.fsf@gitster.g> (raw)
In-Reply-To: <a76dda61-f60c-4221-83db-5e165a2478b1@gmail.com> (Phillip Wood's message of "Sat, 17 May 2025 14:39:38 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> As brian has already said I think it would be better to have a
> Makefile knob to control this which defaults to being on for
> linux. Take a look at the various USE_xxx definitions in the Makefile
> and config.mak.uname for setting default compile flags for different
> operating systems.
>
>> Also another check if a socket is supported by looking for a return
>> value of
>> "EAI_SOCKTYPE" (not EINVAL) and fallback to regular TCP if that is
>> returned.
>> EAI_SOCKTYPE should work across different UNIX systems as this is a
>> posix error code.
>
> That error is not mentioned in the documentation for MCTCP on Linux
> [1]. Please make sure your code checks for the errno values described
> in the documentation.
Also according to RFC 6897, "MPTCP is designed to be totally
backward compatible to applications". I understand that this is
quite unlike introducing IPv6 into IPv4-only world. You can tell
the system that supports MPTCP to use it in specific ways by
updating your application, but your system's local policy may
allow MPTCP to automatically set up multiple subflows even your
application is not quite aware of MPTCP.
So, ... I somehow would be mildly surprised if Git were a kind of
application that needs to take advantage of "several additional
degrees of freedom that applications may wish to exploit" by using
API that is "a simple extension of TCP's interface for MPTCP-aware
applications". Requiring a simple application like ours to tweak
and rebuild in today's world does not sound like a winning strategy
to promote a technology that "is designed to be totally backward
compatible to applications", at least to me.
next prev parent reply other threads:[~2025-05-19 23:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 17:56 Small patch to add support for MPTCP on Linux Muhammad Nuzaihan
2025-05-16 20:33 ` brian m. carlson
2025-05-17 7:19 ` Muhammad Nuzaihan
[not found] ` <CAOYsWhkMb8hxjnYRTgAb269N=e-Vyw10Go5M=RA-8PyCjXPttA@mail.gmail.com>
2025-05-17 8:46 ` Muhammad Nuzaihan
2025-05-17 10:15 ` brian m. carlson
2025-05-17 13:10 ` Muhammad Nuzaihan
2025-05-17 13:39 ` Phillip Wood
2025-05-19 23:49 ` Junio C Hamano [this message]
2025-05-20 4:32 ` Muhammad Nuzaihan
2025-05-20 10:54 ` Matthieu Baerts
2025-05-20 15:44 ` Junio C Hamano
2025-05-20 20:34 ` Matthieu Baerts
2025-05-20 22:02 ` Junio C Hamano
2025-05-22 11:12 ` Matthieu Baerts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqo6vokvpv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=zaihan@unrealasia.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).