Netdev List
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	 Willem de Bruijn <willemb@google.com>
Cc: netdev@vger.kernel.org,  David Ahern <dsahern@kernel.org>,
	 Jason Xing <kerneljasonxing@gmail.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Simon Horman <horms@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH net-next v3 2/4] net_tstamp: add SCM_TS_OPT_ID for TCP sockets
Date: Thu, 05 Sep 2024 12:39:23 -0400	[thread overview]
Message-ID: <66d9debb2d2ea_1eae1a2943d@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <3e4add99-6b57-4fe1-9ee1-519c80cf7cf5@linux.dev>

Vadim Fedorenko wrote:
> On 04/09/2024 12:31, Vadim Fedorenko wrote:
> > TCP sockets have different flow for providing timestamp OPT_ID value.
> > Adjust the code to support SCM_TS_OPT_ID option for TCP sockets.
> > 
> > Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
> > ---
> >   net/ipv4/tcp.c | 13 +++++++++----
> >   1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 8a5680b4e786..5553a8aeee80 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -474,9 +474,10 @@ void tcp_init_sock(struct sock *sk)
> >   }
> >   EXPORT_SYMBOL(tcp_init_sock);
> >   
> > -static void tcp_tx_timestamp(struct sock *sk, u16 tsflags)
> > +static void tcp_tx_timestamp(struct sock *sk, struct sockcm_cookie *sockc)
> >   {
> >   	struct sk_buff *skb = tcp_write_queue_tail(sk);
> > +	u32 tsflags = sockc->tsflags;
> >   
> >   	if (tsflags && skb) {
> >   		struct skb_shared_info *shinfo = skb_shinfo(skb);
> > @@ -485,8 +486,12 @@ static void tcp_tx_timestamp(struct sock *sk, u16 tsflags)
> >   		sock_tx_timestamp(sk, tsflags, &shinfo->tx_flags);
> >   		if (tsflags & SOF_TIMESTAMPING_TX_ACK)
> >   			tcb->txstamp_ack = 1;
> > -		if (tsflags & SOF_TIMESTAMPING_TX_RECORD_MASK)
> > -			shinfo->tskey = TCP_SKB_CB(skb)->seq + skb->len - 1;
> > +		if (tsflags & SOF_TIMESTAMPING_TX_RECORD_MASK) {
> > +			if (tsflags & SOCKCM_FLAG_TS_OPT_ID)
> > +				shinfo->tskey = sockc->ts_opt_id;
> > +			else
> > +				shinfo->tskey = TCP_SKB_CB(skb)->seq + skb->len - 1;
> > +		}
> >   	}
> >   }
> >   
> > @@ -1318,7 +1323,7 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> >   
> >   out:
> >   	if (copied) {
> > -		tcp_tx_timestamp(sk, sockc.tsflags);
> > +		tcp_tx_timestamp(sk, &sockc);
> >   		tcp_push(sk, flags, mss_now, tp->nonagle, size_goal);
> >   	}
> >   out_nopush:
> 
> Hi Willem,
> 
> Unfortunately, these changes are not enough to enable custom OPT_ID for
> TCP sockets. There are some functions which rewrite shinfo->tskey in TCP
> flow:
> 
> tcp_skb_collapse_tstamp()
> tcp_fragment_tstamp()
> tcp_gso_tstamp()
> 
> I believe the last one breaks tests, but the problem is that there is no
> easy way to provide the flag of constant tskey to it. Only
> shinfo::tx_flags are available at the caller side and we have already
> discussed that we shouldn't use the last bit of this field.
> 
> So, how should we deal with the problem? Or is it better to postpone
> support for TCP sockets in this case?

Are you sure that this is a problem. These functions pass on the
skb_shinfo(skb)->ts_key from one skb to another.

As long as tcp_tx_timestamp sets the skb_shinfo(skb)->ts_key of the
original skb correctly, either from the cmsg or sk_tskey, then I don't
immediate see how this passing on from one skb to another would break
the intent.


  parent reply	other threads:[~2024-09-05 16:39 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
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 [this message]
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=66d9debb2d2ea_1eae1a2943d@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=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