[PATCHv5 net-next] bonding: add software tx timestamping support

[PATCHv5 net-next] bonding: add software tx timestamping support

[Hangbin Liu]

Currently, bonding only obtain the timestamp (ts) information of
the active slave, which is available only for modes 1, 5, and 6.
For other modes, bonding only has software rx timestamping support.

However, some users who use modes such as LACP also want tx timestamp
support. To address this issue, let's check the ts information of each
slave. If all slaves support tx timestamping, we can enable tx
timestamping support for the bond.

Add a note that the get_ts_info may be called with RCU, or rtnl or
reference on the device in ethtool.h>

Suggested-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
v5: remove ASSERT_RTNL since bond_ethtool_get_ts_info could be called
    without RTNL. Update ethtool kdoc.
v4: add ASSERT_RTNL to make sure bond_ethtool_get_ts_info() called via
    RTNL. Only check _TX_SOFTWARE for the slaves.
v3: remove dev_hold/dev_put. remove the '\' for line continuation.
v2: check each slave's ts info to make sure bond support sw tx
    timestamping
---
 drivers/net/bonding/bond_main.c | 30 ++++++++++++++++++++++++++++++
 include/linux/ethtool.h         |  1 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 8cc9a74789b7..db7e650d9ebb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -5696,9 +5696,13 @@ static int bond_ethtool_get_ts_info(struct net_device *bond_dev,
 				    struct ethtool_ts_info *info)
 {
 	struct bonding *bond = netdev_priv(bond_dev);
+	struct ethtool_ts_info ts_info;
 	const struct ethtool_ops *ops;
 	struct net_device *real_dev;
+	bool sw_tx_support = false;
 	struct phy_device *phydev;
+	struct list_head *iter;
+	struct slave *slave;
 	int ret = 0;
 
 	rcu_read_lock();
@@ -5717,10 +5721,36 @@ static int bond_ethtool_get_ts_info(struct net_device *bond_dev,
 			ret = ops->get_ts_info(real_dev, info);
 			goto out;
 		}
+	} else {
+		/* Check if all slaves support software tx timestamping */
+		rcu_read_lock();
+		bond_for_each_slave_rcu(bond, slave, iter) {
+			ret = -1;
+			ops = slave->dev->ethtool_ops;
+			phydev = slave->dev->phydev;
+
+			if (phy_has_tsinfo(phydev))
+				ret = phy_ts_info(phydev, &ts_info);
+			else if (ops->get_ts_info)
+				ret = ops->get_ts_info(slave->dev, &ts_info);
+
+			if (!ret && (ts_info.so_timestamping & SOF_TIMESTAMPING_TX_SOFTWARE)) {
+				sw_tx_support = true;
+				continue;
+			}
+
+			sw_tx_support = false;
+			break;
+		}
+		rcu_read_unlock();
 	}
 
+	ret = 0;
 	info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE |
 				SOF_TIMESTAMPING_SOFTWARE;
+	if (sw_tx_support)
+		info->so_timestamping |= SOF_TIMESTAMPING_TX_SOFTWARE;
+
 	info->phc_index = -1;
 
 out:
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 798d35890118..62b61527bcc4 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -711,6 +711,7 @@ struct ethtool_mm_stats {
  * @get_dump_data: Get dump data.
  * @set_dump: Set dump specific flags to the device.
  * @get_ts_info: Get the time stamping and PTP hardware clock capabilities.
+ *	It may be called with RCU, or rtnl or reference on the device.
  *	Drivers supporting transmit time stamps in software should set this to
  *	ethtool_op_get_ts_info().
  * @get_module_info: Get the size and type of the eeprom contained within
-- 
2.38.1

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[Jakub Kicinski]

On Tue, 18 Apr 2023 11:48:41 +0800 Hangbin Liu wrote:
> Currently, bonding only obtain the timestamp (ts) information of
> the active slave, which is available only for modes 1, 5, and 6.
> For other modes, bonding only has software rx timestamping support.
> 
> However, some users who use modes such as LACP also want tx timestamp
> support. To address this issue, let's check the ts information of each
> slave. If all slaves support tx timestamping, we can enable tx
> timestamping support for the bond.
> 
> Add a note that the get_ts_info may be called with RCU, or rtnl or
> reference on the device in ethtool.h>
> 
> Suggested-by: Miroslav Lichvar <mlichvar@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> ---
> v5: remove ASSERT_RTNL since bond_ethtool_get_ts_info could be called
>     without RTNL. Update ethtool kdoc.

I'll apply Jay's ack from v4 since these are not substantial changes.
Thanks!

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[Hangbin Liu]

On Tue, Apr 18, 2023 at 08:50:23PM -0700, Jakub Kicinski wrote:
> On Tue, 18 Apr 2023 11:48:41 +0800 Hangbin Liu wrote:
> > Currently, bonding only obtain the timestamp (ts) information of
> > the active slave, which is available only for modes 1, 5, and 6.
> > For other modes, bonding only has software rx timestamping support.
> > 
> > However, some users who use modes such as LACP also want tx timestamp
> > support. To address this issue, let's check the ts information of each
> > slave. If all slaves support tx timestamping, we can enable tx
> > timestamping support for the bond.
> > 
> > Add a note that the get_ts_info may be called with RCU, or rtnl or
> > reference on the device in ethtool.h>
> > 
> > Suggested-by: Miroslav Lichvar <mlichvar@redhat.com>
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> > ---
> > v5: remove ASSERT_RTNL since bond_ethtool_get_ts_info could be called
> >     without RTNL. Update ethtool kdoc.
> 
> I'll apply Jay's ack from v4 since these are not substantial changes.
> Thanks!

Sorry, not sure if I missed something. bond_ethtool_get_ts_info() could be
called without RTNL. And we have ASSERT_RTNL() in v4.

Thanks
Hangbin

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[Jakub Kicinski]

On Wed, 19 Apr 2023 12:09:17 +0800 Hangbin Liu wrote:
> > I'll apply Jay's ack from v4 since these are not substantial changes.
> > Thanks!  
> 
> Sorry, not sure if I missed something. bond_ethtool_get_ts_info() could be
> called without RTNL. And we have ASSERT_RTNL() in v4.

Are there any documented best practices on when to keep an ack?
I'm not aware of such a doc, it's a bit of a gray zone.
IMHO the changes here weren't big enough to drop Jay's tag.

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 18 Apr 2023 11:48:41 +0800 you wrote:
> Currently, bonding only obtain the timestamp (ts) information of
> the active slave, which is available only for modes 1, 5, and 6.
> For other modes, bonding only has software rx timestamping support.
> 
> However, some users who use modes such as LACP also want tx timestamp
> support. To address this issue, let's check the ts information of each
> slave. If all slaves support tx timestamping, we can enable tx
> timestamping support for the bond.
> 
> [...]

Here is the summary with links:
  - [PATCHv5,net-next] bonding: add software tx timestamping support
    https://git.kernel.org/netdev/net-next/c/980f0799a15c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[Jay Vosburgh]

Jakub Kicinski <kuba@kernel.org> wrote:

>On Wed, 19 Apr 2023 12:09:17 +0800 Hangbin Liu wrote:
>> > I'll apply Jay's ack from v4 since these are not substantial changes.
>> > Thanks!  
>> 
>> Sorry, not sure if I missed something. bond_ethtool_get_ts_info() could be
>> called without RTNL. And we have ASSERT_RTNL() in v4.
>
>Are there any documented best practices on when to keep an ack?
>I'm not aware of such a doc, it's a bit of a gray zone.
>IMHO the changes here weren't big enough to drop Jay's tag.

	I don't know of any such documents, but just to clarify for
posterity, I'm fine with having my ack on the patch.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

Re: [PATCHv5 net-next] bonding: add software tx timestamping support

[Hangbin Liu]

On Tue, Apr 18, 2023 at 09:17:46PM -0700, Jakub Kicinski wrote:
> On Wed, 19 Apr 2023 12:09:17 +0800 Hangbin Liu wrote:
> > > I'll apply Jay's ack from v4 since these are not substantial changes.
> > > Thanks!  
> > 
> > Sorry, not sure if I missed something. bond_ethtool_get_ts_info() could be
> > called without RTNL. And we have ASSERT_RTNL() in v4.
> 
> Are there any documented best practices on when to keep an ack?
> I'm not aware of such a doc, it's a bit of a gray zone.
> IMHO the changes here weren't big enough to drop Jay's tag.

I don't know either. Some times I also struggle on whether I should keep the
ack tag, then I drop the tag just in case the reviewer doesn't agree with my
change.

Anyway, thanks a lot for your patient review and comments.

Regards
Hangbin