Subject: Re: [PATCH net-next] bonding: add software timestamping support

From: Jay Vosburgh <[email-masked]>
Date: Wed, 29 Mar 2023 21:12:44 -0700

Hangbin Liu <[email-masked]> wrote:

>On Wed, Mar 29, 2023 at 12:27:11PM +0200, Miroslav Lichvar wrote:
>> On Wed, Mar 29, 2023 at 11:13:37AM +0800, Hangbin Liu wrote:
>> > At present, bonding attempts to obtain the timestamp (ts) information of
>> > the active slave. However, this feature is only available for mode 1, 5,
>> > and 6. For other modes, bonding doesn't even provide support for software
>> > timestamping. To address this issue, let's call ethtool_op_get_ts_info
>> > when there is no primary active slave. This will enable the use of software
>> > timestamping for the bonding interface.
>> 
>> Would it make sense to check if all devices in the bond support
>> SOF_TIMESTAMPING_TX_SOFTWARE before returning it for the bond?
>> Applications might expect that a SW TX timestamp will be always
>> provided if the capability is reported.
>
>In my understanding this is a software feature, no need for hardware support.
>In __sock_tx_timestamp() it will set skb tx_flags when we have
>SOF_TIMESTAMPING_TX_SOFTWARE flag. Do I understand wrong?

	Right, but the network device driver is required to call
skb_tx_timestamp() in order to record the actual timestamp for the
software timestamping case.

	Do all drivers that may be members of a bond return
SOF_TIMESTAMPING_TX_SOFTWARE to .get_ts_info and properly call
skb_tx_timestamp()?  I.e., is this something that needs to be checked,
or is it safe to assume it's always true?

	If I'm reading things correctly, the answer is no, as one
exception appears to be IPOIB, which doesn't define .get_ts_info that I
can find, and does not call skb_tx_timestamp() in ipoib_start_xmit().

	-J

---
	-Jay Vosburgh, [email-masked]