Messages in this thread | | | Date | Wed, 10 Apr 2024 06:19:28 -0700 | From | Jakub Kicinski <> | Subject | Re: [PATCH net-next] gve: Correctly report software timestamping capabilities |
| |
On Tue, 09 Apr 2024 21:40:46 -0700 Rahul Rameshbabu wrote: > > My gut tells me we force drivers to set the ethtool op because > > while at it they will probably also implement tx stamping. > > I think the logic should be the other way (in terms of the > relationship). A call to skb_tx_timestamp should throw a warning if the > driver does not advertise its timestamping capabilities. This way, a > naive netdev driver for some lightweight device does not need to worry > about this. I agree that anyone implementing tx timestamping should have > this operation defined. An skb does not contain any mechanism to > reference the driver's ethtool callback. Maybe the right choice is to > have a ts capability function registered for each netdev that can be > used by the core stack and that powers the ethtool operation as well > instead of the existing callback for ethtool?
Adding a check which only need to runs once in the lifetime of the driver to the fastpath may be a little awkward. Another option would be a sufficiently intelligent grep, which would understand which files constitute a driver. At which point grepping for the ethtool op and skb_tx_timestamp would be trivial?
| |