[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <661d9a8bb862c_314dd2942c@willemb.c.googlers.com.notmuch>
Date: Mon, 15 Apr 2024 17:22:19 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: "Abhishek Chauhan (ABC)" <quic_abchauha@...cinc.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Andrew Halaney <ahalaney@...hat.com>,
Martin KaFai Lau <martin.lau@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Daniel Borkmann <daniel@...earbox.net>,
bpf <bpf@...r.kernel.org>
Cc: kernel@...cinc.com
Subject: Re: [RFC PATCH bpf-next v3 1/2] net: Rename mono_delivery_time to
tstamp_type for scalabilty
> >>>> static inline void skb_set_delivery_time(struct sk_buff *skb, ktime_t kt,
> >>>> - bool mono)
> >>>> + u8 tstamp_type)
> >>>> {
> >>>> skb->tstamp = kt;
> >>>> - skb->mono_delivery_time = kt && mono;
> >>>> +
> >>>> + switch (tstamp_type) {
> >>>> + case CLOCK_REAL:
> >>>> + skb->tstamp_type = CLOCK_REAL;
> >>>> + break;
> >>>> + case CLOCK_MONO:
> >>>> + skb->tstamp_type = kt && tstamp_type;
> >>>> + break;
> >>>> + }
> >>>
> >>> Technically this leaves the tstamp_type undefined if (skb, 0, CLOCK_REAL)
> >> Do you think i should be checking for valid value of tstamp before setting the tstamp_type ? Only then set it.
> >
> > A kt of 0 is interpreted as resetting the type. That should probably
> > be maintained.
> >
> > For SO_TIMESTAMPING, a mono delivery time of 0 does have some meaning.
> > In __sock_recv_timestamp:
> >
> > /* Race occurred between timestamp enabling and packet
> > receiving. Fill in the current time for now. */
> > if (need_software_tstamp && skb->tstamp == 0) {
> > __net_timestamp(skb);
> > false_tstamp = 1;
> > }
>
> Well in that case the above logic still resets the tstamp and sets the tstamp_type to CLOCK_REAL(value 0).
> Anyway the tstamp_type will be 0 to begin with.
> The logic is still inline with previous implementation, because previously if kt was 0 then kt && mono sets the tstamp_type (previously called as mono_delivery_time) to 0 (i.e SKB_CLOCK_REAL).
Sorry, I got my defaults confused. If we maintain that a zero tstamp
resets the type, then here should be no case with skb->tstamp 0 and
skb->tstamp_type SKB_CLOCK_REAL (or SKB_CLOCK_TAI or whatever). I
think it's preferable to make that obvious in the
skb_set_delivery_time implementation, rather than depend on knowledge
of its callers.
Powered by blists - more mailing lists