From: Matthieu Baerts <matttbe@kernel.org>
To: Gang Yan <gang.yan@linux.dev>, mptcp@lists.linux.dev
Cc: Gang Yan <yangang@kylinos.cn>
Subject: Re: [RFC mptcp-next] mptcp: support MSG_EOR in mptcp_sendmsg
Date: Mon, 2 Feb 2026 11:28:01 +0100 [thread overview]
Message-ID: <2cf2897c-00dd-4f1a-aceb-404959a8eb4c@kernel.org> (raw)
In-Reply-To: <20260202040916.626066-1-gang.yan@linux.dev>
Hi Gang,
On 02/02/2026 05:09, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
>
> This patch adds support for the MSG_EOR flag in MPTCP's sendmsg path,
> ensuring that data fragments marked with MSG_EOR are properly handled
> to prevent coalescing with subsequent data.
>
> Key changes:
> 1. Added an 'eor' field to struct mptcp_data_frag to track MSG_EOR marking
> 2. Initialize the eor field to 0 in mptcp_carve_data_frag()
> 3. In mptcp_sendmsg_frag(), when sending the last chunk of a data fragment
> that has MSG_EOR set, mark the corresponding skb with TCP_SKB_CB(skb)->eor = 1
> to prevent coalescing with subsequent data
> 4. Modified mptcp_sendmsg() to:
> - Preserve MSG_EOR flag in msg_flags filtering
> - Mark the last pending data fragment with eor = 1 when MSG_EOR is set
> in the message flags
>
> This ensures that applications using MSG_EOR to indicate record boundaries
> have their intent preserved across MPTCP subflows, maintaining proper
> message segmentation semantics.
Thank you for looking at this.
>
> Signed-off-by: Gang Yan <yangang@kylinos.cn>
> ---
>
> Notes:
> Hi Matt,
>
> I create two packetdrill scripts to test the 'MSG_EOR' in
> single/multi subflow(s). The link is attached below:
> https://github.com/multipath-tcp/packetdrill/compare/mptcp-net-next...Dwyane-Yan:packetdrill:mptcp-net-next
>
> Please ignore the indent problems, I will fix them when
> the 'MSG_EOR' patch is accepted.
I think it is better to be able to review the tests at the same time as
the implementation. Can you then fix the indent problems and open a PR
please?
In the meantime, it looks like checkpatch is complaining here:
> WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
> #14:
> that has MSG_EOR set, mark the corresponding skb with TCP_SKB_CB(skb)->eor = 1
>
> WARNING: line length of 107 exceeds 80 columns
> #95: FILE: net/mptcp/protocol.h:270:
> + u8 eor; /* Is MSG_EOR marked? Prevents coalescing with next frag */
>
> total: 0 errors, 2 warnings, 0 checks, 54 lines checked
Can you look at that, please?
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
prev parent reply other threads:[~2026-02-02 10:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 4:09 [RFC mptcp-next] mptcp: support MSG_EOR in mptcp_sendmsg Gang Yan
2026-02-02 5:36 ` MPTCP CI
2026-02-02 10:28 ` Matthieu Baerts [this message]
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=2cf2897c-00dd-4f1a-aceb-404959a8eb4c@kernel.org \
--to=matttbe@kernel.org \
--cc=gang.yan@linux.dev \
--cc=mptcp@lists.linux.dev \
--cc=yangang@kylinos.cn \
/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