From: Matthieu Baerts <matttbe@kernel.org>
To: Kalpan Jani <kalpan.jani@mpiricsoftware.com>, mptcp@lists.linux.dev
Cc: martineau@kernel.org, pabeni@redhat.com,
shardul.b@mpiricsoftware.com, janak@mpiric.us,
kalpanjani009@gmail.com
Subject: Re: [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info
Date: Mon, 31 Aug 2026 12:29:46 +0200 [thread overview]
Message-ID: <f0fabe59-0a2b-4df9-983d-446eab20104c@kernel.org> (raw)
In-Reply-To: <20260827041058.2833707-1-kalpan.jani@mpiricsoftware.com>
Hi Kalpan,
On 27/08/2026 06:10, Kalpan Jani wrote:
> mptcpi_write_seq, mptcpi_snd_una and mptcpi_rcv_nxt report the raw
> 64-bit data sequence numbers, seeded from the connection's IDSN/IASN.
> Since the IDSN/IASN come from mptcp_crypto_key_sha(), these fields
> carry an effectively random offset and are not useful to userspace as
> absolute values: a caller has to snapshot two getsockopt(MPTCP_INFO)
> calls and subtract to get anything meaningful, which is exactly what
> tools/testing/selftests/net/mptcp/mptcp_sockopt.c already does.
>
> mptcp_info also reports mptcpi_bytes_sent, mptcpi_bytes_received and
> mptcpi_bytes_acked, which give the same information as a plain byte
> count starting at 0. The snapshot-and-diff workaround for the seq
> fields is redundant once those are available.
Thank you for looking at this!
> Cache the local and remote initial sequence numbers on the
> mptcp_sock the same way ->token already is, and subtract them in
> mptcp_diag_fill_info(), so mptcpi_write_seq, mptcpi_snd_una and
> mptcpi_rcv_nxt also start near 0 for a freshly established
> connection.
Not to increase msk's size for these fields only used in the diag side
(under the msk lock I think), couldn't you get the info from the first
subflow instead? It should always be available (except when being
disconnected, but the other fields should be 0 in this case, no?)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2026-08-31 10:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 4:10 [PATCH net-next v2] mptcp: normalize seq numbers reported in mptcp_info Kalpan Jani
2026-08-27 5:15 ` MPTCP CI
2026-08-31 10:29 ` Matthieu Baerts [this message]
2026-09-01 5:19 ` Kalpan Jani
2026-09-01 5:55 ` Matthieu Baerts
2026-09-02 6:48 ` Kalpan Jani
2026-09-02 7:46 ` Matthieu Baerts
-- strict thread matches above, loose matches on Subject: below --
2026-08-25 11:33 [PATCH net-next] " Kalpan Jani
2026-08-26 6:03 ` [PATCH net-next v2] " Kalpan Jani
2026-08-26 7:26 ` MPTCP CI
2026-08-26 9:48 ` Kalpan Jani
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=f0fabe59-0a2b-4df9-983d-446eab20104c@kernel.org \
--to=matttbe@kernel.org \
--cc=janak@mpiric.us \
--cc=kalpan.jani@mpiricsoftware.com \
--cc=kalpanjani009@gmail.com \
--cc=martineau@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=shardul.b@mpiricsoftware.com \
/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