On Thu, Feb 6, 2025 at 4:43 PM Jason Xing <kerneljasonxing@xxxxxxxxx> wrote: > > On Wed, Feb 5, 2025 at 11:34 PM Willem de Bruijn > <willemdebruijn.kernel@xxxxxxxxx> wrote: > > > > Jason Xing wrote: > > > No functional changes here, only add skb_enable_app_tstamp() to test > > > if the orig_skb matches the usage of application SO_TIMESTAMPING > > > or its bpf extension. And it's good to support two modes in > > > parallel later in this series. > > > > > > Also, this patch deliberately distinguish the software and > > > hardware SCM_TSTAMP_SND timestamp by passing 'sw' parameter in order > > > to avoid such a case where hardware may go wrong and pass a NULL > > > hwstamps, which is even though unlikely to happen. If it really > > > happens, bpf prog will finally consider it as a software timestamp. > > > It will be hardly recognized. Let's make the timestamping part > > > more robust. > > > > Disagree. Don't add a crutch that has not shown to be necessary for > > all this time. > > > > Just infer hw from hwtstamps != NULL. > > I can surely modify this part as you said, but may I ask why? I cannot > find a good reason to absolutely trust the hardware behaviour. If that > corner case happens, it would be very hard to trace the root cause... No offense, just curious. I can keep the same approach as SO_TIMESTAMPING since you disagree. I have no strong preference because I found It's simpler after rewriting this part. I will simplify this patch in v9 :) Thanks, Jason
