net: Bluetooth: add TX timestamping for ISO/L2CAP/SCO

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst +6 -0

+  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
 ^^^^^^^^^^^^^^^^^^^^^^^^^

include/uapi/linux/errqueue.h +1 -0

index 3c70e8ac14b8..1ea47309d772 100644
@@ -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 */

include/uapi/linux/net_tstamp.h +4 -2

index 55b0ab51096c..383213de612a 100644
@@ -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

net/core/sock.c +2 -0

index a197f0a0b878..76a5d5cb1e56 100644
@@ -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;

net/ethtool/common.c +1 -1

index 5489d0c9d13f..ed4d6a9f4d7e 100644
@@ -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

Quoted 37 lines · Pauli Virtanen

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst SOF_TIMESTAMPING_TX_ACK: · line 145

Quoted 6 lines

Documentation/networking/timestamping.rst +3 -0

@@ -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?

Quoted 51 lines · Jason Xing

Quoted 37 lines · Pauli Virtanen

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst SOF_TIMESTAMPING_TX_ACK: · line 145

Quoted 6 lines

Documentation/networking/timestamping.rst +3 -0

@@ -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.

Quoted 4 lines

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?

This is a workaround around the limited number of bits available in skb_shared_info.tx_flags.

Pauli could claim last available bit 7.. but then you would need to find another bit for SKBTX_BPF ;)

FWIW I think we could probably free up 1 or 2 bits if we look closely, e.g., of SKBTX_HW_TSTAMP_USE_CYCLES or SKBTX_WIFI_STATUS.

But given that two uses for those bits are in review at the same time, I doubt that this is the last such feature that is added.

This workaround is clever. Only, we're leaking implementation limitations into the API, making it API non-uniform and thus more complex.

On the one hand, the feature should work just like all the existing ones, and thus be configurable independently, and maintaining a consistent API. But, this does require a tx_flags bit. And the same for each subsequent such feature that gets proposed.

On the other, if we can anticipate more such additional requests, then perhaps it does make sense to use only one bit in the skb to encode whether the skb is sampled (in this case SKBTX_SW_TSTAMP), and use per-socket sk_tsflags to encode which types of timestamps to generate for such sampled packets.

This is more or less how sampling in the new BPF mode works too.

It is just not how SO_TIMESTAMPING works for existing bits.

There's something to be said for either approach IMHO.

Quoted 53 lines · Willem de Bruijn

Quoted 51 lines · Jason Xing

Quoted 37 lines · Pauli Virtanen

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst SOF_TIMESTAMPING_TX_ACK: · line 145

Quoted 6 lines

Documentation/networking/timestamping.rst +3 -0

@@ -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.

Quoted 7 lines

Quoted 4 lines

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?

This is a workaround around the limited number of bits available in skb_shared_info.tx_flags.

Oh, I'm surprised I missed the point even though I revisited the previous discussion.

Pauli, please add the limitation when users setsockopt in sock_set_timestamping() :)

Quoted 3 lines

Pauli could claim last available bit 7.. but then you would need to find another bit for SKBTX_BPF ;)

Right :D

Quoted 3 lines

FWIW I think we could probably free up 1 or 2 bits if we look closely, e.g., of SKBTX_HW_TSTAMP_USE_CYCLES or SKBTX_WIFI_STATUS.

Good. Will you submit a patch series to do that, or...?

Quoted 8 lines

But given that two uses for those bits are in review at the same time, I doubt that this is the last such feature that is added.

This workaround is clever. Only, we're leaking implementation limitations into the API, making it API non-uniform and thus more complex.

Probably not a big deal because previously OPT_ID_TCP is also bound with OPT_ID?

Quoted 6 lines

On the one hand, the feature should work just like all the existing ones, and thus be configurable independently, and maintaining a consistent API. But, this does require a tx_flags bit. And the same for each subsequent such feature that gets proposed.

Quoted 5 lines

On the other, if we can anticipate more such additional requests, then perhaps it does make sense to use only one bit in the skb to encode whether the skb is sampled (in this case SKBTX_SW_TSTAMP), and use per-socket sk_tsflags to encode which types of timestamps to generate for such sampled packets.

Very good idea, I think.

Quoted 5 lines

This is more or less how sampling in the new BPF mode works too.

It is just not how SO_TIMESTAMPING works for existing bits.

If needed, especially when a new bit is added, I think we can refactor this part in the future? Or can we adjust it in advance? Speaking of the design itself, it's really good :)

Thanks,
Jason

Quoted 3 lines

There's something to be said for either approach IMHO.

Quoted 79 lines · Jason Xing

Quoted 53 lines · Willem de Bruijn

Quoted 51 lines · Jason Xing

Quoted 37 lines · Pauli Virtanen

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst SOF_TIMESTAMPING_TX_ACK: · line 145

Quoted 6 lines

Documentation/networking/timestamping.rst +3 -0

@@ -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.

Quoted 7 lines

Quoted 4 lines

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?

This is a workaround around the limited number of bits available in skb_shared_info.tx_flags.

Oh, I'm surprised I missed the point even though I revisited the previous discussion.

Pauli, please add the limitation when users setsockopt in sock_set_timestamping() :)

Quoted 3 lines

Pauli could claim last available bit 7.. but then you would need to find another bit for SKBTX_BPF ;)

Right :D

Quoted 3 lines

FWIW I think we could probably free up 1 or 2 bits if we look closely, e.g., of SKBTX_HW_TSTAMP_USE_CYCLES or SKBTX_WIFI_STATUS.

Quoted 1 line

Good. Will you submit a patch series to do that, or...?

Reclaiming space is really up to whoever needs it.

I'll take a quick look, just to see if there is an obvious path and we can postpone this whole conversation to next time we need a bit.

Quoted 82 lines · Willem de Bruijn

Quoted 80 lines · Jason Xing

Quoted 53 lines · Willem de Bruijn

Quoted 51 lines · Jason Xing

Quoted 37 lines · Pauli Virtanen

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 <[email protected]>

---

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(-)

Documentation/networking/timestamping.rst +0 -0

index 61ef9da10e28..5034dfe326c0 100644

Documentation/networking/timestamping.rst SOF_TIMESTAMPING_TX_ACK: · line 145

Quoted 6 lines

Documentation/networking/timestamping.rst +3 -0

@@ -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.

Quoted 7 lines

Quoted 4 lines

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?

This is a workaround around the limited number of bits available in skb_shared_info.tx_flags.

Oh, I'm surprised I missed the point even though I revisited the previous discussion.

Pauli, please add the limitation when users setsockopt in sock_set_timestamping() :)

Quoted 3 lines

Pauli could claim last available bit 7.. but then you would need to find another bit for SKBTX_BPF ;)

Right :D

Quoted 3 lines

FWIW I think we could probably free up 1 or 2 bits if we look closely, e.g., of SKBTX_HW_TSTAMP_USE_CYCLES or SKBTX_WIFI_STATUS.

Good. Will you submit a patch series to do that, or...?

Quoted 4 lines

Reclaiming space is really up to whoever needs it.

I'll take a quick look, just to see if there is an obvious path and we can postpone this whole conversation to next time we need a bit.

SKBTX_HW_TSTAMP_USE_CYCLES is only true if SOF_TIMESTAMPING_BIND_PHC. It cannot be set per cmsg (is not in SOF_TIMESTAMPING_TX_RECORD_MASK), so no need to record it per skb.

It only has two drivers using it, which can easily be updated:

- if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_USE_CYCLES)
+ if (skb->sk &&
+ READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_BIND_PHC)
tx_flags |= IGC_TX_FLAGS_TSTAMP_TIMER_1;

They later call skb_tstamp_tx, which does nothing if !skb->sk. Only cost is a higher cost of accessing the sk cacheline.

SKBTX_WIFI_STATUS essentially follows the same argument. It can only be set in the sockopt. It has a handful more callsites that would need to be updated. sock_flag(sk, SOCK_WIFI_STATUS) will be tested without the socket lock held. But this is already the case in the UDP lockless fast path through ip_make_skb.

SKBTX_HW_TSTAMP_NETDEV is only used on Rx. Could shadow another bit that is used only on Tx.

SKBTX_IN_PROGRESS is only used by the driver to suppress the software tx timestamp from skb_tx_timestamp if a later hardware timestamp will be generated. Predates SOF_TIMESTAMPING_OPT_TX_SWHW.

In short plenty of bits we can reclaim if we try.

SKBTX_BPF was just merged, so we will have to reclaim one.

The first one seems most straightforward.

Willem de Bruijn wrote:

Quoted 5 lines

Reclaiming space is really up to whoever needs it.

I'll take a quick look, just to see if there is an obvious path and we can postpone this whole conversation to next time we need a bit.

SKBTX_HW_TSTAMP_USE_CYCLES is only true if SOF_TIMESTAMPING_BIND_PHC. It cannot be set per cmsg (is not in SOF_TIMESTAMPING_TX_RECORD_MASK), so no need to record it per skb.

It only has two drivers using it, which can easily be updated:

- if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_USE_CYCLES)
+ if (skb->sk &&
+ READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_BIND_PHC)
tx_flags |= IGC_TX_FLAGS_TSTAMP_TIMER_1;

They later call skb_tstamp_tx, which does nothing if !skb->sk. Only cost is a higher cost of accessing the sk cacheline.

SKBTX_WIFI_STATUS essentially follows the same argument. It can only be set in the sockopt. It has a handful more callsites that would need to be updated. sock_flag(sk, SOCK_WIFI_STATUS) will be tested without the socket lock held. But this is already the case in the UDP lockless fast path through ip_make_skb.

SKBTX_HW_TSTAMP_NETDEV is only used on Rx. Could shadow another bit that is used only on Tx.

SKBTX_IN_PROGRESS is only used by the driver to suppress the software tx timestamp from skb_tx_timestamp if a later hardware timestamp will be generated. Predates SOF_TIMESTAMPING_OPT_TX_SWHW.

In short plenty of bits we can reclaim if we try.

SKBTX_BPF was just merged, so we will have to reclaim one. The first one seems most straightforward.

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

Changes
=======
v4:
- Change meaning of SOF_TIMESTAMPING_TX_COMPLETION, to save a bit in skb_shared_info.tx_flags:

It now enables COMPLETION only for packets that also have software SND enabled. The flag can now be enabled only via a socket option, but coupling with SND allows user to still choose for which packets SND+COMPLETION should be generated. This choice maybe is OK for applications which can skip SND if they're not interested.

However, this would make the timestamping API not uniform, as the other TX flags can be enabled via CMSG.

IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure there is somewhere else in general skb info, where one could safely put the extra separate flag bit for COMPLETION. So here's alternative suggestion.

- Better name in sof_timestamping_names

- I decided to keep using sockcm_init(), to avoid open coding READ_ONCE and since it's passed to sock_cmsg_send() which anyway also may init such fields.

v3:
- Add new COMPLETION timestamp type, and emit it in HCI completion.
- Emit SND instead of SCHED, when sending to driver.
- Do not emit SCHED timestamps.
- Don't safeguard tx_q length explicitly. Now that hci_sched_acl_blk() is no more, the scheduler flow control is guaranteed to keep it bounded.
- Fix L2CAP stream sockets to use the bytestream timestamp conventions.

Overview
========

The packet flow in Bluetooth is the following. Timestamps added here indicated:

user sendmsg() generates skbs
|
* skb waits in net/bluetooth queue for a free HW packet slot |
* orphan skb, send to driver -> TSTAMP_SND
|
* driver: send packet data to transport (eg. USB)
|
* wait for transport completion
|
* driver: transport tx completion, free skb (some do this immediately) |
* packet waits in HW side queue
|
* HCI report for packet completion -> TSTAMP_COMPLETION (for non-SCO)

In addition, we may want to do the following in future (but not implemented in this series as we don't have ISO sequence number synchronization yet which is needed first, moreover e.g. Intel controllers return only zeros in timestamps):

* if packet is ISO, send HCI LE Read ISO TX Sync
|
* HCI response -> hardware TSTAMP_SND for the packet the response corresponds to if it was waiting for one, might not be possible to get a tstamp for every packet

Bluetooth does not have tx timestamps in the completion reports from hardware, and only for ISO packets there are HCI commands in specification for querying timestamps afterward.

The drivers do not provide ways to get timestamps either, I'm also not aware if some devices would have vendor-specific commands to get them.

Driver-side timestamps
======================

Generating SND on driver side may be slightly more accurate, but that requires changing the BT driver API to not orphan skbs first. In theory this probably won't cause problems, but it is not done in this patchset.

For some of the drivers it won't gain much. E.g. btusb immediately submits the URB, so if one would emit SND just before submit (as drivers/net/usb/usbnet.c does), it is essentially identical to emitting before sending to driver. btintel_pcie looks like it does synchronous send, so looks the same. hci_serdev has internal queue, iiuc flushing as fast as data can be transferred, but it shouldn't be waiting for hardware slots due to HCI flow control.

Unless HW buffers are full, packets mostly wait on the HW side. E.g. with btusb (non-SCO) median time from sendmsg() to URB generation is ~0.1 ms, to USB completion ~0.5 ms, and HCI completion report at ~5 ms.

The exception is SCO, for which HCI flow control is disabled, so they do not get completion events so it's possible to build up queues inside the driver. For SCO, COMPLETION needs to be generated from driver side, eg. for btusb maybe at URB completion. This could be useful for SCO PCM modes (but which are more or less obsolete nowadays), where USB isoc data rate matches audio data rate, so queues on USB side may build up.

Use cases
=========

In audio use cases we want to track and avoid queues building up, to control latency, especially in cases like ISO where the controller has a fixed schedule that the sending application must match. E.g. application can aim to keep 1 packet in HW queue, so it has 2*7.5ms of slack for being woken up too late.

Applications can use SND & COMPLETION timestamps to track in-kernel and in-HW packet queues separately. This can matter for ISO, where the specification allows HW to use the timings when it gets packets to determine what packets are synchronized together. Applications can use SND to track that.

Tests
=====

See
https://lore.kernel.org/linux-bluetooth/[email protected]/

Pauli Virtanen (5):
net-timestamp: COMPLETION timestamp on packet tx completion
Bluetooth: add support for skb TX SND/COMPLETION timestamping
Bluetooth: ISO: add TX timestamping
Bluetooth: L2CAP: add TX timestamping
Bluetooth: SCO: add TX timestamping socket-level mechanism

 Documentation/networking/timestamping.rst |   9 ++
 include/net/bluetooth/bluetooth.h         |   1 +
 include/net/bluetooth/hci_core.h          |  13 +++
 include/net/bluetooth/l2cap.h             |   3 +-
 include/uapi/linux/errqueue.h             |   1 +
 include/uapi/linux/net_tstamp.h           |   6 +-
 net/bluetooth/6lowpan.c                   |   2 +-
 net/bluetooth/hci_conn.c                  | 118 ++++++++++++++++++++++
 net/bluetooth/hci_core.c                  |  17 +++-
 net/bluetooth/hci_event.c                 |   4 +
 net/bluetooth/iso.c                       |  24 ++++-
 net/bluetooth/l2cap_core.c                |  41 +++++++-
 net/bluetooth/l2cap_sock.c                |  15 ++-
 net/bluetooth/sco.c                       |  19 +++-
 net/bluetooth/smp.c                       |   2 +-
 net/core/sock.c                           |   2 +
 net/ethtool/common.c                      |   1 +
 17 files changed, 258 insertions(+), 20 deletions(-)

--
2.48.1

Hi Pauli,

Quoted 26 lines · Pauli Virtanen

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

Changes
=======
v4:
- Change meaning of SOF_TIMESTAMPING_TX_COMPLETION, to save a bit in skb_shared_info.tx_flags:

It now enables COMPLETION only for packets that also have software SND enabled. The flag can now be enabled only via a socket option, but coupling with SND allows user to still choose for which packets SND+COMPLETION should be generated. This choice maybe is OK for applications which can skip SND if they're not interested.

However, this would make the timestamping API not uniform, as the other TX flags can be enabled via CMSG.

Quoted 4 lines

IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure there is somewhere else in general skb info, where one could safely put the extra separate flag bit for COMPLETION. So here's alternative suggestion.

Due to cloning/dup of socket by bluetoothd wouldn't it be better to have the completion on a per-packet basis?

Not really sure if that is what setting it via CMSG would mean,

but in the other hand perhaps the
problem is that the error queue is socket wide, not per-fd, anyway it doesn't sound very useful to notify the completion on all fd pointing to the same socket. Or perhaps it is time for introducing a proper TX complete queue rather than reuse the error queue? I mean we can keep using the error queue for backwards compatibility but moving forward I think it would be better not to mix errors with tx complete events, so perhaps we can add something like a socket option that dissociates the error queue from tx completion queue.

Quoted 131 lines

- Better name in sof_timestamping_names

- I decided to keep using sockcm_init(), to avoid open coding READ_ONCE and since it's passed to sock_cmsg_send() which anyway also may init such fields.

v3:
- Add new COMPLETION timestamp type, and emit it in HCI completion.
- Emit SND instead of SCHED, when sending to driver.
- Do not emit SCHED timestamps.
- Don't safeguard tx_q length explicitly. Now that hci_sched_acl_blk() is no more, the scheduler flow control is guaranteed to keep it bounded.
- Fix L2CAP stream sockets to use the bytestream timestamp conventions.

Overview
========

The packet flow in Bluetooth is the following. Timestamps added here indicated:

user sendmsg() generates skbs

Quoted 1 line

* skb waits in net/bluetooth queue for a free HW packet slot

Quoted 1 line

* orphan skb, send to driver -> TSTAMP_SND

Quoted 1 line

* driver: send packet data to transport (eg. USB)

Quoted 1 line

* wait for transport completion

Quoted 1 line

* driver: transport tx completion, free skb (some do this immediately)

Quoted 1 line

* packet waits in HW side queue

Quoted 1 line

* HCI report for packet completion -> TSTAMP_COMPLETION (for non-SCO)

In addition, we may want to do the following in future (but not implemented in this series as we don't have ISO sequence number synchronization yet which is needed first, moreover e.g. Intel controllers return only zeros in timestamps):

* if packet is ISO, send HCI LE Read ISO TX Sync

Quoted 1 line

* HCI response -> hardware TSTAMP_SND for the packet the response corresponds to if it was waiting for one, might not be possible to get a tstamp for every packet

Bluetooth does not have tx timestamps in the completion reports from hardware, and only for ISO packets there are HCI commands in specification for querying timestamps afterward.

The drivers do not provide ways to get timestamps either, I'm also not aware if some devices would have vendor-specific commands to get them.

Driver-side timestamps
======================

Generating SND on driver side may be slightly more accurate, but that requires changing the BT driver API to not orphan skbs first. In theory this probably won't cause problems, but it is not done in this patchset.

For some of the drivers it won't gain much. E.g. btusb immediately submits the URB, so if one would emit SND just before submit (as drivers/net/usb/usbnet.c does), it is essentially identical to emitting before sending to driver. btintel_pcie looks like it does synchronous send, so looks the same. hci_serdev has internal queue, iiuc flushing as fast as data can be transferred, but it shouldn't be waiting for hardware slots due to HCI flow control.

Unless HW buffers are full, packets mostly wait on the HW side. E.g. with btusb (non-SCO) median time from sendmsg() to URB generation is ~0.1 ms, to USB completion ~0.5 ms, and HCI completion report at ~5 ms.

The exception is SCO, for which HCI flow control is disabled, so they do not get completion events so it's possible to build up queues inside the driver. For SCO, COMPLETION needs to be generated from driver side, eg. for btusb maybe at URB completion. This could be useful for SCO PCM modes (but which are more or less obsolete nowadays), where USB isoc data rate matches audio data rate, so queues on USB side may build up.

Use cases
=========

In audio use cases we want to track and avoid queues building up, to control latency, especially in cases like ISO where the controller has a fixed schedule that the sending application must match. E.g. application can aim to keep 1 packet in HW queue, so it has 2*7.5ms of slack for being woken up too late.

Applications can use SND & COMPLETION timestamps to track in-kernel and in-HW packet queues separately. This can matter for ISO, where the specification allows HW to use the timings when it gets packets to determine what packets are synchronized together. Applications can use SND to track that.

Tests
=====

See
https://lore.kernel.org/linux-bluetooth/[email protected]/

Pauli Virtanen (5):
net-timestamp: COMPLETION timestamp on packet tx completion
Bluetooth: add support for skb TX SND/COMPLETION timestamping
Bluetooth: ISO: add TX timestamping
Bluetooth: L2CAP: add TX timestamping
Bluetooth: SCO: add TX timestamping socket-level mechanism

 Documentation/networking/timestamping.rst |   9 ++
 include/net/bluetooth/bluetooth.h         |   1 +
 include/net/bluetooth/hci_core.h          |  13 +++
 include/net/bluetooth/l2cap.h             |   3 +-
 include/uapi/linux/errqueue.h             |   1 +
 include/uapi/linux/net_tstamp.h           |   6 +-
 net/bluetooth/6lowpan.c                   |   2 +-
 net/bluetooth/hci_conn.c                  | 118 ++++++++++++++++++++++
 net/bluetooth/hci_core.c                  |  17 +++-
 net/bluetooth/hci_event.c                 |   4 +
 net/bluetooth/iso.c                       |  24 ++++-
 net/bluetooth/l2cap_core.c                |  41 +++++++-
 net/bluetooth/l2cap_sock.c                |  15 ++-
 net/bluetooth/sco.c                       |  19 +++-
 net/bluetooth/smp.c                       |   2 +-
 net/core/sock.c                           |   2 +
 net/ethtool/common.c                      |   1 +
 17 files changed, 258 insertions(+), 20 deletions(-)

--
2.48.1

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

Changes
=======
v4:
- Change meaning of SOF_TIMESTAMPING_TX_COMPLETION, to save a bit in skb_shared_info.tx_flags:

It now enables COMPLETION only for packets that also have software SND enabled. The flag can now be enabled only via a socket option, but coupling with SND allows user to still choose for which packets SND+COMPLETION should be generated. This choice maybe is OK for applications which can skip SND if they're not interested.

However, this would make the timestamping API not uniform, as the other TX flags can be enabled via CMSG.

IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure there is somewhere else in general skb info, where one could safely put the extra separate flag bit for COMPLETION. So here's alternative suggestion.

- Better name in sof_timestamping_names

- I decided to keep using sockcm_init(), to avoid open coding READ_ONCE and since it's passed to sock_cmsg_send() which anyway also may init such fields.

v3:
- Add new COMPLETION timestamp type, and emit it in HCI completion.
- Emit SND instead of SCHED, when sending to driver.
- Do not emit SCHED timestamps.
- Don't safeguard tx_q length explicitly. Now that hci_sched_acl_blk() is no more, the scheduler flow control is guaranteed to keep it bounded.
- Fix L2CAP stream sockets to use the bytestream timestamp conventions.

Overview
========

The packet flow in Bluetooth is the following. Timestamps added here indicated:

user sendmsg() generates skbs
|
* skb waits in net/bluetooth queue for a free HW packet slot |
* orphan skb, send to driver -> TSTAMP_SND
|
* driver: send packet data to transport (eg. USB)
|
* wait for transport completion
|
* driver: transport tx completion, free skb (some do this immediately) |
* packet waits in HW side queue
|
* HCI report for packet completion -> TSTAMP_COMPLETION (for non-SCO)

In addition, we may want to do the following in future (but not implemented in this series as we don't have ISO sequence number synchronization yet which is needed first, moreover e.g. Intel controllers return only zeros in timestamps):

* if packet is ISO, send HCI LE Read ISO TX Sync
|
* HCI response -> hardware TSTAMP_SND for the packet the response corresponds to if it was waiting for one, might not be possible to get a tstamp for every packet

Bluetooth does not have tx timestamps in the completion reports from hardware, and only for ISO packets there are HCI commands in specification for querying timestamps afterward.

The drivers do not provide ways to get timestamps either, I'm also not aware if some devices would have vendor-specific commands to get them.

Driver-side timestamps
======================

Generating SND on driver side may be slightly more accurate, but that requires changing the BT driver API to not orphan skbs first. In theory this probably won't cause problems, but it is not done in this patchset.

For some of the drivers it won't gain much. E.g. btusb immediately submits the URB, so if one would emit SND just before submit (as drivers/net/usb/usbnet.c does), it is essentially identical to emitting before sending to driver. btintel_pcie looks like it does synchronous send, so looks the same. hci_serdev has internal queue, iiuc flushing as fast as data can be transferred, but it shouldn't be waiting for hardware slots due to HCI flow control.

Unless HW buffers are full, packets mostly wait on the HW side. E.g. with btusb (non-SCO) median time from sendmsg() to URB generation is ~0.1 ms, to USB completion ~0.5 ms, and HCI completion report at ~5 ms.

The exception is SCO, for which HCI flow control is disabled, so they do not get completion events so it's possible to build up queues inside the driver. For SCO, COMPLETION needs to be generated from driver side, eg. for btusb maybe at URB completion. This could be useful for SCO PCM modes (but which are more or less obsolete nowadays), where USB isoc data rate matches audio data rate, so queues on USB side may build up.

Use cases
=========

In audio use cases we want to track and avoid queues building up, to control latency, especially in cases like ISO where the controller has a fixed schedule that the sending application must match. E.g. application can aim to keep 1 packet in HW queue, so it has 2*7.5ms of slack for being woken up too late.

Applications can use SND & COMPLETION timestamps to track in-kernel and in-HW packet queues separately. This can matter for ISO, where the specification allows HW to use the timings when it gets packets to determine what packets are synchronized together. Applications can use SND to track that.

Tests
=====

See
https://lore.kernel.org/linux-bluetooth/[email protected]/

Pauli Virtanen (5):
net-timestamp: COMPLETION timestamp on packet tx completion
Bluetooth: add support for skb TX SND/COMPLETION timestamping
Bluetooth: ISO: add TX timestamping
Bluetooth: L2CAP: add TX timestamping
Bluetooth: SCO: add TX timestamping socket-level mechanism

 Documentation/networking/timestamping.rst |   9 ++
 include/net/bluetooth/bluetooth.h         |   1 +
 include/net/bluetooth/hci_core.h          |  13 +++
 include/net/bluetooth/l2cap.h             |   3 +-
 include/uapi/linux/errqueue.h             |   1 +
 include/uapi/linux/net_tstamp.h           |   6 +-
 net/bluetooth/6lowpan.c                   |   2 +-
 net/bluetooth/hci_conn.c                  | 118 ++++++++++++++++++++++
 net/bluetooth/hci_core.c                  |  17 +++-
 net/bluetooth/hci_event.c                 |   4 +
 net/bluetooth/iso.c                       |  24 ++++-
 net/bluetooth/l2cap_core.c                |  41 +++++++-
 net/bluetooth/l2cap_sock.c                |  15 ++-
 net/bluetooth/sco.c                       |  19 +++-
 net/bluetooth/smp.c                       |   2 +-
 net/core/sock.c                           |   2 +
 net/ethtool/common.c                      |   1 +
 17 files changed, 258 insertions(+), 20 deletions(-)

--
2.48.1

Quoted 31 lines · Pauli Virtanen

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

Changes
=======
v4:
- Change meaning of SOF_TIMESTAMPING_TX_COMPLETION, to save a bit in skb_shared_info.tx_flags:

It now enables COMPLETION only for packets that also have software SND enabled. The flag can now be enabled only via a socket option, but coupling with SND allows user to still choose for which packets SND+COMPLETION should be generated. This choice maybe is OK for applications which can skip SND if they're not interested.

However, this would make the timestamping API not uniform, as the other TX flags can be enabled via CMSG.

IIUC, sizeof skb_shared_info cannot be easily changed and I'm not sure there is somewhere else in general skb info, where one could safely put the extra separate flag bit for COMPLETION. So here's alternative suggestion.

Quoted 5 lines

- Better name in sof_timestamping_names

- I decided to keep using sockcm_init(), to avoid open coding READ_ONCE and since it's passed to sock_cmsg_send() which anyway also may init such fields.

Please don't do this since the current sockcm_init() initializes more than you need. Please take a look at what the new sockcm_init looks like and what this series has done[1] which just got merged in recent days :)

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=aefd232de5eb2e7

Thanks,
Jason

Quoted 127 lines

v3:
- Add new COMPLETION timestamp type, and emit it in HCI completion.
- Emit SND instead of SCHED, when sending to driver.
- Do not emit SCHED timestamps.
- Don't safeguard tx_q length explicitly. Now that hci_sched_acl_blk() is no more, the scheduler flow control is guaranteed to keep it bounded.
- Fix L2CAP stream sockets to use the bytestream timestamp conventions.

Overview
========

The packet flow in Bluetooth is the following. Timestamps added here indicated:

user sendmsg() generates skbs
|
* skb waits in net/bluetooth queue for a free HW packet slot |
* orphan skb, send to driver -> TSTAMP_SND
|
* driver: send packet data to transport (eg. USB)
|
* wait for transport completion
|
* driver: transport tx completion, free skb (some do this immediately) |
* packet waits in HW side queue
|
* HCI report for packet completion -> TSTAMP_COMPLETION (for non-SCO)

In addition, we may want to do the following in future (but not implemented in this series as we don't have ISO sequence number synchronization yet which is needed first, moreover e.g. Intel controllers return only zeros in timestamps):

* if packet is ISO, send HCI LE Read ISO TX Sync
|
* HCI response -> hardware TSTAMP_SND for the packet the response corresponds to if it was waiting for one, might not be possible to get a tstamp for every packet

Bluetooth does not have tx timestamps in the completion reports from hardware, and only for ISO packets there are HCI commands in specification for querying timestamps afterward.

The drivers do not provide ways to get timestamps either, I'm also not aware if some devices would have vendor-specific commands to get them.

Driver-side timestamps
======================

Generating SND on driver side may be slightly more accurate, but that requires changing the BT driver API to not orphan skbs first. In theory this probably won't cause problems, but it is not done in this patchset.

For some of the drivers it won't gain much. E.g. btusb immediately submits the URB, so if one would emit SND just before submit (as drivers/net/usb/usbnet.c does), it is essentially identical to emitting before sending to driver. btintel_pcie looks like it does synchronous send, so looks the same. hci_serdev has internal queue, iiuc flushing as fast as data can be transferred, but it shouldn't be waiting for hardware slots due to HCI flow control.

Unless HW buffers are full, packets mostly wait on the HW side. E.g. with btusb (non-SCO) median time from sendmsg() to URB generation is ~0.1 ms, to USB completion ~0.5 ms, and HCI completion report at ~5 ms.

The exception is SCO, for which HCI flow control is disabled, so they do not get completion events so it's possible to build up queues inside the driver. For SCO, COMPLETION needs to be generated from driver side, eg. for btusb maybe at URB completion. This could be useful for SCO PCM modes (but which are more or less obsolete nowadays), where USB isoc data rate matches audio data rate, so queues on USB side may build up.

Use cases
=========

In audio use cases we want to track and avoid queues building up, to control latency, especially in cases like ISO where the controller has a fixed schedule that the sending application must match. E.g. application can aim to keep 1 packet in HW queue, so it has 2*7.5ms of slack for being woken up too late.

Applications can use SND & COMPLETION timestamps to track in-kernel and in-HW packet queues separately. This can matter for ISO, where the specification allows HW to use the timings when it gets packets to determine what packets are synchronized together. Applications can use SND to track that.

Tests
=====

See
https://lore.kernel.org/linux-bluetooth/[email protected]/

Pauli Virtanen (5):
net-timestamp: COMPLETION timestamp on packet tx completion
Bluetooth: add support for skb TX SND/COMPLETION timestamping
Bluetooth: ISO: add TX timestamping
Bluetooth: L2CAP: add TX timestamping
Bluetooth: SCO: add TX timestamping socket-level mechanism

 Documentation/networking/timestamping.rst |   9 ++
 include/net/bluetooth/bluetooth.h         |   1 +
 include/net/bluetooth/hci_core.h          |  13 +++
 include/net/bluetooth/l2cap.h             |   3 +-
 include/uapi/linux/errqueue.h             |   1 +
 include/uapi/linux/net_tstamp.h           |   6 +-
 net/bluetooth/6lowpan.c                   |   2 +-
 net/bluetooth/hci_conn.c                  | 118 ++++++++++++++++++++++
 net/bluetooth/hci_core.c                  |  17 +++-
 net/bluetooth/hci_event.c                 |   4 +
 net/bluetooth/iso.c                       |  24 ++++-
 net/bluetooth/l2cap_core.c                |  41 +++++++-
 net/bluetooth/l2cap_sock.c                |  15 ++-
 net/bluetooth/sco.c                       |  19 +++-
 net/bluetooth/smp.c                       |   2 +-
 net/core/sock.c                           |   2 +
 net/ethtool/common.c                      |   1 +
 17 files changed, 258 insertions(+), 20 deletions(-)

--
2.48.1

Hi Pauli,

Quoted 12 lines · Jason Xing

Quoted 10 lines · Pauli Virtanen

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

We are sort of running out of time, if we want to be able to merge by the next merge window then it must be done this week.

ma, 2025-03-17 kello 13:50 -0400, Luiz Augusto von Dentz kirjoitti:

Quoted 15 lines

Hi Pauli,

Quoted 12 lines · Jason Xing

Quoted 10 lines · Pauli Virtanen

Add support for TX timestamping in Bluetooth ISO/L2CAP/SCO sockets.

Add new COMPLETION timestamp type, to report a software timestamp when the hardware reports a packet completed. (Cc netdev for this)

Previous discussions:
https://lore.kernel.org/linux-bluetooth/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/

[clip]

Quoted 3 lines

We are sort of running out of time, if we want to be able to merge by the next merge window then it must be done this week.

It took a bit of time to get back to it, but v5 is sent now.

Note that it does not apply cleanly on bluetooth-next/master, as the first commit is based on net-next since there have been some changes there that need to be taken into account here:

commit e6116fc605574bb58c2016938ff24a7fbafe6e2a

Author: Willem de Bruijn <[email protected]>
Date:   Tue Feb 25 04:33:55 2025

net: skb: free up one bit in tx_flags

commit aa290f93a4af662b8d2d9e9df65798f9f24cecf3

Author: Jason Xing <[email protected]>
Date:   Thu Feb 20 09:29:33 2025

net-timestamp: Prepare for isolating two modes of SO_TIMESTAMPING