Netdev List
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Vadim Fedorenko <vadfed@meta.com>,
	 Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	 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: Vadim Fedorenko <vadfed@meta.com>,  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: Wed, 04 Sep 2024 16:54:27 -0400	[thread overview]
Message-ID: <66d8c903bba20_163d9329498@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20240904113153.2196238-2-vadfed@meta.com>

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.

> 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/

> +		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.



  parent reply	other threads:[~2024-09-04 20:54 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 [this message]
2024-09-05 10:10     ` Vadim Fedorenko
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=66d8c903bba20_163d9329498@willemb.c.googlers.com.notmuch \
    --to=willemdebruijn.kernel@gmail.com \
    --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=vadim.fedorenko@linux.dev \
    --cc=willemb@google.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