lkml.org 
[lkml]   [2024]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?

\
 
 \ /
  Last update: 2024-05-27 16:32    [W:0.116 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site