From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Vadim Fedorenko <vadfed@meta.com>,
Willem de Bruijn <willemb@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
David Ahern <dsahern@kernel.org>,
Jason Xing <kerneljasonxing@gmail.com>,
Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next v3 1/4] net_tstamp: add SCM_TS_OPT_ID to provide OPT_ID in control message
Date: Thu, 5 Sep 2024 11:10:25 +0100 [thread overview]
Message-ID: <1946af56-9f6f-439d-b954-6bcb82367741@linux.dev> (raw)
In-Reply-To: <66d8c903bba20_163d9329498@willemb.c.googlers.com.notmuch>
On 04/09/2024 21:54, Willem de Bruijn wrote:
> Vadim Fedorenko wrote:
>> SOF_TIMESTAMPING_OPT_ID socket option flag gives a way to correlate TX
>> timestamps and packets sent via socket. Unfortunately, there is no way
>> to reliably predict socket timestamp ID value in case of error returned
>> by sendmsg. For UDP sockets it's impossible because of lockless
>> nature of UDP transmit, several threads may send packets in parallel. In
>> case of RAW sockets MSG_MORE option makes things complicated. More
>> details are in the conversation [1].
>> This patch adds new control message type to give user-space
>> software an opportunity to control the mapping between packets and
>> values by providing ID with each sendmsg for UDP sockets.
>> The documentation is also added in this patch.
>>
>> [1] https://lore.kernel.org/netdev/CALCETrU0jB+kg0mhV6A8mrHfTE1D1pr1SD_B9Eaa9aDPfgHdtA@mail.gmail.com/
>>
>> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
>> ---
>> Documentation/networking/timestamping.rst | 13 +++++++++++++
>> arch/alpha/include/uapi/asm/socket.h | 2 ++
>> arch/mips/include/uapi/asm/socket.h | 2 ++
>> arch/parisc/include/uapi/asm/socket.h | 2 ++
>> arch/sparc/include/uapi/asm/socket.h | 2 ++
>> include/net/inet_sock.h | 4 +++-
>> include/net/sock.h | 2 ++
>> include/uapi/asm-generic/socket.h | 2 ++
>> include/uapi/linux/net_tstamp.h | 7 +++++++
>> net/core/sock.c | 9 +++++++++
>> net/ipv4/ip_output.c | 18 +++++++++++++-----
>> net/ipv6/ip6_output.c | 18 +++++++++++++-----
>> 12 files changed, 70 insertions(+), 11 deletions(-)
>>
>> diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
>> index a2c66b3d7f0f..1c38536350e7 100644
>> --- a/include/uapi/linux/net_tstamp.h
>> +++ b/include/uapi/linux/net_tstamp.h
>> @@ -38,6 +38,13 @@ enum {
>> SOF_TIMESTAMPING_LAST
>> };
>>
>> +/*
>> + * The highest bit of sk_tsflags is reserved for kernel-internal
>> + * SOCKCM_FLAG_TS_OPT_ID. This check is to control that SOF_TIMESTAMPING*
>> + * values do not reach this reserved area
>> + */
>> +static_assert(SOF_TIMESTAMPING_LAST != (1 << 31));
>
> Let's not leak any if this implementation detail to include/uapi.
>
> A BUILD_BUG_ON wherever SOCKCM_FLAG_TS_OPT_ID is used, such as in case
> SCM_TS_OPT_ID, should work.
Makes sense. I'll change the check and will try to add meaningful message.
>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> index eea443b7f65e..bd2f6a699470 100644
>> --- a/net/ipv4/ip_output.c
>> +++ b/net/ipv4/ip_output.c
>> @@ -973,7 +973,7 @@ static int __ip_append_data(struct sock *sk,
>> unsigned int maxfraglen, fragheaderlen, maxnonfragsize;
>> int csummode = CHECKSUM_NONE;
>> struct rtable *rt = dst_rtable(cork->dst);
>> - bool paged, hold_tskey, extra_uref = false;
>> + bool paged, hold_tskey = false, extra_uref = false;
>> unsigned int wmem_alloc_delta = 0;
>> u32 tskey = 0;
>>
>> @@ -1049,10 +1049,15 @@ static int __ip_append_data(struct sock *sk,
>>
>> cork->length += length;
>>
>> - hold_tskey = cork->tx_flags & SKBTX_ANY_TSTAMP &&
>> - READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_OPT_ID;
>> - if (hold_tskey)
>> - tskey = atomic_inc_return(&sk->sk_tskey) - 1;
>> + if (cork->tx_flags & SKBTX_ANY_TSTAMP &&
>> + READ_ONCE(sk->sk_tsflags) & SOCKCM_FLAG_TS_OPT_ID) {
>
> s/SOCKCM_FLAG_TS_OPT_ID/SOF_TIMESTAMPING_OPT_ID/
Ack
>> + if (cork->flags & IPCORK_TS_OPT_ID) {
>> + tskey = cork->ts_opt_id;
>> + } else {
>> + tskey = atomic_inc_return(&sk->sk_tskey) - 1;
>> + hold_tskey = true;
>> + }
>> + }
>>
>> /* So, what's going on in the loop below?
>> *
>> @@ -1325,8 +1330,11 @@ static int ip_setup_cork(struct sock *sk, struct inet_cork *cork,
>> cork->mark = ipc->sockc.mark;
>> cork->priority = ipc->priority;
>> cork->transmit_time = ipc->sockc.transmit_time;
>> + cork->ts_opt_id = ipc->sockc.ts_opt_id;
>> cork->tx_flags = 0;
>> sock_tx_timestamp(sk, ipc->sockc.tsflags, &cork->tx_flags);
>> + if (ipc->sockc.tsflags & SOCKCM_FLAG_TS_OPT_ID)
>> + cork->flags |= IPCORK_TS_OPT_ID;
>
> We can move initialization of ts_opt_id into the branch.
>
> Or conversely avoid the branch with some convoluted shift operations
> to have the rval be either 1 << 1 or 0 << 1. But let's do the simpler
> thing.
What is the reason to move initialization behind the flag? We are not
doing this for transmit_time even though it's also used with flag only.
It's not a big deal to change, I just wonder what are the benefits?
next prev parent reply other threads:[~2024-09-05 10:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 11:31 [PATCH net-next v3 0/4] Add option to provide OPT_ID value via cmsg Vadim Fedorenko
2024-09-04 11:31 ` [PATCH net-next v3 1/4] net_tstamp: add SCM_TS_OPT_ID to provide OPT_ID in control message Vadim Fedorenko
2024-09-04 13:56 ` Jason Xing
2024-09-04 14:01 ` Vadim Fedorenko
2024-09-04 20:54 ` Willem de Bruijn
2024-09-05 10:10 ` Vadim Fedorenko [this message]
2024-09-05 13:29 ` Willem de Bruijn
2024-09-05 8:24 ` Jason Xing
2024-09-05 8:34 ` Vadim Fedorenko
2024-09-05 8:49 ` Jason Xing
2024-09-06 9:22 ` kernel test robot
2024-09-06 12:58 ` kernel test robot
2024-09-04 11:31 ` [PATCH net-next v3 2/4] net_tstamp: add SCM_TS_OPT_ID for TCP sockets Vadim Fedorenko
2024-09-05 14:58 ` Vadim Fedorenko
2024-09-05 15:37 ` Jason Xing
2024-09-05 16:39 ` Willem de Bruijn
2024-09-06 12:20 ` Vadim Fedorenko
2024-09-06 15:25 ` Willem de Bruijn
2024-09-06 16:33 ` Willem de Bruijn
2024-09-06 17:27 ` Vadim Fedorenko
2024-09-06 23:50 ` Willem de Bruijn
2024-09-06 17:27 ` Vadim Fedorenko
2024-09-06 23:48 ` Willem de Bruijn
2024-09-07 21:55 ` Vadim Fedorenko
2024-09-08 19:19 ` Willem de Bruijn
2024-09-08 19:55 ` Vadim Fedorenko
2024-09-04 11:31 ` [PATCH net-next v3 3/4] net_tstamp: add SCM_TS_OPT_ID for RAW sockets Vadim Fedorenko
2024-09-04 11:31 ` [PATCH net-next v3 4/4] selftests: txtimestamp: add SCM_TS_OPT_ID test Vadim Fedorenko
2024-09-04 11:36 ` [PATCH net-next v3 0/4] Add option to provide OPT_ID value via cmsg Vadim Fedorenko
2024-09-04 21:04 ` Willem de Bruijn
2024-09-04 22:50 ` Vadim Fedorenko
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=1946af56-9f6f-439d-b954-6bcb82367741@linux.dev \
--to=vadim.fedorenko@linux.dev \
--cc=dsahern@kernel.org \
--cc=horms@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vadfed@meta.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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;
as well as URLs for NNTP newsgroup(s).