On Sat, Sep 7, 2024 at 9:23 AM Jason Xing <kerneljasonxing@xxxxxxxxx> wrote: > > On Sat, Sep 7, 2024 at 7:24 AM Willem de Bruijn > <willemdebruijn.kernel@xxxxxxxxx> wrote: > > > > Jason Xing wrote: > > > From: Jason Xing <kernelxing@xxxxxxxxxxx> > > > > > > introduce a new flag SOF_TIMESTAMPING_OPT_RX_FILTER in the receive > > > path. User can set it with SOF_TIMESTAMPING_SOFTWARE to filter > > > out rx software timestamp report, especially after a process turns on > > > netstamp_needed_key which can time stamp every incoming skb. > > > > > > Previously, we found out if an application starts first which turns on > > > netstamp_needed_key, then another one only passing SOF_TIMESTAMPING_SOFTWARE > > > could also get rx timestamp. Now we handle this case by introducing this > > > new flag without breaking users. > > > > > > Quoting Willem to explain why we need the flag: > > > "why a process would want to request software timestamp reporting, but > > > not receive software timestamp generation. The only use I see is when > > > the application does request > > > SOF_TIMESTAMPING_SOFTWARE | SOF_TIMESTAMPING_TX_SOFTWARE." > > > > > > Similarly, this new flag could also be used for hardware case where we > > > can set it with SOF_TIMESTAMPING_RAW_HARDWARE, then we won't receive > > > hardware receive timestamp. > > > > > > Another thing about errqueue in this patch I have a few words to say: > > > In this case, we need to handle the egress path carefully, or else > > > reporting the tx timestamp will fail. Egress path and ingress path will > > > finally call sock_recv_timestamp(). We have to distinguish them. > > > Errqueue is a good indicator to reflect the flow direction. > > > > > > Suggested-by: Willem de Bruijn <willemb@xxxxxxxxxx> > > > Signed-off-by: Jason Xing <kernelxing@xxxxxxxxxxx> > > > > High level: where is the harm in receiving unsolicited timestamps? > > A process can easily ignore them. I do wonder if the only use case is > > an overly strict testcase. Was reminded of this as I tried to write > > a more concise paragraph for the documentation. > > You raised a good question. > > I think It's more of a design consideration instead of a bugfix > actually. So it is not solving a bug which makes the apps wrong but > gives users a hint that we can explicitly and accurately do what we > want and we expect. One more thing: if I recall correctly, the initial reason I proposed is that the rx report flag is not controlled under per socket but maybe affected by others. It's against the expectation.
