From: "Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Andrew Halaney <ahalaney@redhat.com>,
"Martin KaFai Lau" <martin.lau@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, bpf <bpf@vger.kernel.org>,
<kernel@quicinc.com>
Subject: Re: [RFC PATCH bpf-next v6 2/3] net: Add additional bit to support clockid_t timestamp type
Date: Tue, 7 May 2024 12:08:24 -0700 [thread overview]
Message-ID: <fc8334a6-6961-41f4-affc-28bdfc3dd697@quicinc.com> (raw)
In-Reply-To: <663a12f089b81_726ea29426@willemb.c.googlers.com.notmuch>
On 5/7/2024 4:39 AM, Willem de Bruijn wrote:
> Martin KaFai Lau wrote:
>> On 5/3/24 8:13 PM, Abhishek Chauhan wrote:
>>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>>> index fe86cadfa85b..c3d852eecb01 100644
>>> --- a/net/ipv4/ip_output.c
>>> +++ b/net/ipv4/ip_output.c
>>> @@ -1457,7 +1457,10 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
>>>
>>> skb->priority = (cork->tos != -1) ? cork->priority: READ_ONCE(sk->sk_priority);
>>> skb->mark = cork->mark;
>>> - skb->tstamp = cork->transmit_time;
>>> + if (sk_is_tcp(sk))
>>
>> This seems not catching all IPPROTO_TCP case. In particular, the percpu
>> "ipv4_tcp_sk" is SOCK_RAW. sk_is_tcp() is checking SOCK_STREAM:
>>
>> void __init tcp_v4_init(void)
>> {
>>
>> /* ... */
>> res = inet_ctl_sock_create(&sk, PF_INET, SOCK_RAW,
>> IPPROTO_TCP, &init_net);
>>
>> /* ... */
>> }
>>
>> "while :; do ./test_progs -t tc_redirect/tc_redirect_dtime || break; done"
>> failed pretty often exactly in this case.
>>
>
> Interesting. The TCP stack opens non TCP sockets.
>
> Initializing sk->sk_clockid for this socket should address that.
>
Willem, Are you suggesting your point from the previous patch ?
"I think we want to avoid special casing if we can. Note the if.
If TCP always uses monotonic, we could consider initializing
sk_clockid to CLOCK_MONONOTIC in tcp_init_sock.
I guess TCP logic currently entirely ignores sk_clockid. If we are to
start using this, then setsocktop SO_TXTIME must explicitly fail or
ignore for TCP sockets, or silently skip the write.
All of that is more complexity. Than is maybe warranted for this one
case. So no objections from me to special casing using sk_is_tcp(sk)
either."
Few places we need to initialize the clock base for tcp to monotonic
1. tcp_init_sock
2. void __init tcp_v4_init(void) in tcp_ipv4.c
3. static int __net_init tcpv6_net_init(struct net *net)
4. Ignore setsockopts for SO_TXTIME if the sk->protocol is tcp.
Is it safe to assume the TCP will never use any other close base ?
OR
For now we can do just protocol level check in ip_make_skb and ip6_make_skb
like
if (iph->protocol == IPPROTO_TCP)
/* ... */
else
/* ... */
next prev parent reply other threads:[~2024-05-07 19:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-04 3:13 [RFC PATCH bpf-next v6 0/3] Replace mono_delivery_time with tstamp_type Abhishek Chauhan
2024-05-04 3:13 ` [RFC PATCH bpf-next v6 1/3] net: Rename mono_delivery_time to tstamp_type for scalabilty Abhishek Chauhan
2024-05-06 18:51 ` Willem de Bruijn
2024-05-06 19:55 ` Abhishek Chauhan (ABC)
2024-05-06 21:29 ` Willem de Bruijn
2024-05-04 3:13 ` [RFC PATCH bpf-next v6 2/3] net: Add additional bit to support clockid_t timestamp type Abhishek Chauhan
2024-05-06 19:00 ` Willem de Bruijn
2024-05-06 19:57 ` Abhishek Chauhan (ABC)
2024-05-07 0:44 ` Martin KaFai Lau
2024-05-07 11:39 ` Willem de Bruijn
2024-05-07 19:08 ` Abhishek Chauhan (ABC) [this message]
2024-05-07 19:18 ` Willem de Bruijn
2024-05-07 19:38 ` Abhishek Chauhan (ABC)
2024-05-04 3:13 ` [RFC PATCH bpf-next v6 3/3] selftests/bpf: Handle forwarding of UDP CLOCK_TAI packets Abhishek Chauhan
2024-05-06 19:04 ` Willem de Bruijn
2024-05-06 20:50 ` Abhishek Chauhan (ABC)
2024-05-06 20:54 ` Abhishek Chauhan (ABC)
2024-05-06 23:40 ` Abhishek Chauhan (ABC)
2024-05-07 0:54 ` Martin KaFai Lau
2024-05-07 19:15 ` Abhishek Chauhan (ABC)
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=fc8334a6-6961-41f4-affc-28bdfc3dd697@quicinc.com \
--to=quic_abchauha@quicinc.com \
--cc=ahalaney@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kernel@quicinc.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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