Jason Xing wrote:
From: Jason Xing kernelxing@tencent.com
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."
In this way, we have two kinds of combination:
- setting SOF_TIMESTAMPING_SOFTWARE|SOF_TIMESTAMPING_RX_SOFTWARE, it
will surely allow users to get the rx software timestamp report. 2. setting SOF_TIMESTAMPING_SOFTWARE|SOF_TIMESTAMPING_OPT_RX_FILTER while the skb is timestamped, it will stop reporting the rx software 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@google.com Reviewed-by: Willem de Bruijn willemb@google.com
nit: Reviewed-by tags are only sticky if no changes are made.
diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 5e93cd71f99f..37ead02be3b1 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -266,6 +266,18 @@ SOF_TIMESTAMPING_OPT_TX_SWHW: two separate messages will be looped to the socket's error queue, each containing just one timestamp. +SOF_TIMESTAMPING_OPT_RX_FILTER:
- Used in the receive software timestamp. Enabling the flag along with
- SOF_TIMESTAMPING_SOFTWARE will not report the rx timestamp to the
- userspace so that it can filter out the case where one process starts
- first which turns on netstamp_needed_key through setting generation
- flags like SOF_TIMESTAMPING_RX_SOFTWARE, then another one only passing
- SOF_TIMESTAMPING_SOFTWARE report flag could also get the rx timestamp.
This raises the question: why would a process request report flag SOF_TIMESTAMPING_SOFTWARE without generate flag SOF_TIMESTAMPING_RX_SOFTWARE? The only sensible use case I see is when it sets SOF_TIMSETAMPING_TX_SOFTWARE. Probably good to mention that.
May also be good to mention that existing applications sometimes set SOF_TIMESTAMPING_SOFTWARE only, because they implicitly came to depend on another (usually daemon) process to enable rx timestamps systemwide.
- SOF_TIMESTAMPING_OPT_RX_FILTER prevents the application from being
- influenced by others and let the application choose whether to report
- the timestamp in the receive path or not.
I'd drop this paragraph. It's more of a value statement.