| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAL+tcoBxtxCT1R8pPFF2NvDv=1PKris1Gzg-acfKHN9qHr7RFA@mail.gmail.com>
Date: Thu, 20 Feb 2025 09:09:09 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Pauli Virtanen <pav@....fi>
Cc: linux-bluetooth@...r.kernel.org,
Luiz Augusto von Dentz <luiz.dentz@...il.com>, netdev@...r.kernel.org, davem@...emloft.net,
kuba@...nel.org, willemdebruijn.kernel@...il.com
Subject: Re: [PATCH v4 1/5] net-timestamp: COMPLETION timestamp on packet tx completion
On Thu, Feb 20, 2025 at 2:15 AM Pauli Virtanen <pav@....fi> wrote:
>
> Add SOF_TIMESTAMPING_TX_COMPLETION, for requesting a software timestamp
> when hardware reports a packet completed.
>
> Completion tstamp is useful for Bluetooth, as hardware timestamps do not
> exist in the HCI specification except for ISO packets, and the hardware
> has a queue where packets may wait. In this case the software SND
> timestamp only reflects the kernel-side part of the total latency
> (usually small) and queue length (usually 0 unless HW buffers
> congested), whereas the completion report time is more informative of
> the true latency.
>
> It may also be useful in other cases where HW TX timestamps cannot be
> obtained and user wants to estimate an upper bound to when the TX
> probably happened.
>
> Signed-off-by: Pauli Virtanen <pav@....fi>
> ---
>
> Notes:
> v4: changed SOF_TIMESTAMPING_TX_COMPLETION to only emit COMPLETION
> together with SND, to save a bit in skb_shared_info.tx_flags
>
> As it then cannot be set per-skb, reject setting it via CMSG.
>
> Documentation/networking/timestamping.rst | 9 +++++++++
> include/uapi/linux/errqueue.h | 1 +
> include/uapi/linux/net_tstamp.h | 6 ++++--
> net/core/sock.c | 2 ++
> net/ethtool/common.c | 1 +
> 5 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst
> index 61ef9da10e28..5034dfe326c0 100644
> --- a/Documentation/networking/timestamping.rst
> +++ b/Documentation/networking/timestamping.rst
> @@ -140,6 +140,15 @@ SOF_TIMESTAMPING_TX_ACK:
> cumulative acknowledgment. The mechanism ignores SACK and FACK.
> This flag can be enabled via both socket options and control messages.
>
> +SOF_TIMESTAMPING_TX_COMPLETION:
> + Request tx timestamps on packet tx completion, for the packets that
> + also have SOF_TIMESTAMPING_TX_SOFTWARE enabled. The completion
Is it mandatory for other drivers that will try to use
SOF_TIMESTAMPING_TX_COMPLETION in the future? I can see you coupled
both of them in hci_conn_tx_queue in patch [2/5]. If so, it would be
better if you add the limitation in sock_set_timestamping() so that
the same rule can be applied to other drivers.
But may I ask why you tried to couple them so tight in the version?
Could you say more about this? It's optional, right? IIUC, you
expected the driver to have both timestamps and then calculate the
delta easily?
Thanks,
Jason
> + timestamp is generated by the kernel when it receives a packet
> + completion report from the hardware. Hardware may report multiple
> + packets at once, and completion timestamps reflect the timing of the
> + report and not actual tx time. This flag can be enabled *only*
> + via a socket option.
> +
>
> 1.3.2 Timestamp Reporting
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> diff --git a/include/uapi/linux/errqueue.h b/include/uapi/linux/errqueue.h
> index 3c70e8ac14b8..1ea47309d772 100644
> --- a/include/uapi/linux/errqueue.h
> +++ b/include/uapi/linux/errqueue.h
> @@ -73,6 +73,7 @@ enum {
> SCM_TSTAMP_SND, /* driver passed skb to NIC, or HW */
> SCM_TSTAMP_SCHED, /* data entered the packet scheduler */
> SCM_TSTAMP_ACK, /* data acknowledged by peer */
> + SCM_TSTAMP_COMPLETION, /* packet tx completion */
> };
>
> #endif /* _UAPI_LINUX_ERRQUEUE_H */
> diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
> index 55b0ab51096c..383213de612a 100644
> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -44,8 +44,9 @@ enum {
> SOF_TIMESTAMPING_BIND_PHC = (1 << 15),
> SOF_TIMESTAMPING_OPT_ID_TCP = (1 << 16),
> SOF_TIMESTAMPING_OPT_RX_FILTER = (1 << 17),
> + SOF_TIMESTAMPING_TX_COMPLETION = (1 << 18),
>
> - SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_RX_FILTER,
> + SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_TX_COMPLETION,
> SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
> SOF_TIMESTAMPING_LAST
> };
> @@ -58,7 +59,8 @@ enum {
> #define SOF_TIMESTAMPING_TX_RECORD_MASK (SOF_TIMESTAMPING_TX_HARDWARE | \
> SOF_TIMESTAMPING_TX_SOFTWARE | \
> SOF_TIMESTAMPING_TX_SCHED | \
> - SOF_TIMESTAMPING_TX_ACK)
> + SOF_TIMESTAMPING_TX_ACK | \
> + SOF_TIMESTAMPING_TX_COMPLETION)
>
> /**
> * struct so_timestamping - SO_TIMESTAMPING parameter
> diff --git a/net/core/sock.c b/net/core/sock.c
> index a197f0a0b878..76a5d5cb1e56 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2933,6 +2933,8 @@ int __sock_cmsg_send(struct sock *sk, struct cmsghdr *cmsg,
> tsflags = *(u32 *)CMSG_DATA(cmsg);
> if (tsflags & ~SOF_TIMESTAMPING_TX_RECORD_MASK)
> return -EINVAL;
> + if (tsflags & SOF_TIMESTAMPING_TX_COMPLETION)
> + return -EINVAL;
>
> sockc->tsflags &= ~SOF_TIMESTAMPING_TX_RECORD_MASK;
> sockc->tsflags |= tsflags;
> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
> index 5489d0c9d13f..ed4d6a9f4d7e 100644
> --- a/net/ethtool/common.c
> +++ b/net/ethtool/common.c
> @@ -473,6 +473,7 @@ const char sof_timestamping_names[][ETH_GSTRING_LEN] = {
> [const_ilog2(SOF_TIMESTAMPING_BIND_PHC)] = "bind-phc",
> [const_ilog2(SOF_TIMESTAMPING_OPT_ID_TCP)] = "option-id-tcp",
> [const_ilog2(SOF_TIMESTAMPING_OPT_RX_FILTER)] = "option-rx-filter",
> + [const_ilog2(SOF_TIMESTAMPING_TX_COMPLETION)] = "tx-completion",
> };
> static_assert(ARRAY_SIZE(sof_timestamping_names) == __SOF_TIMESTAMPING_CNT);
>
> --
> 2.48.1
>
>
Powered by blists - more mailing lists