All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	John Fraker <jfraker@google.com>,
	netdev@vger.kernel.org,
	Praveen  Kaligineedi <pkaligineedi@google.com>,
	Harshitha Ramamurthy <hramamurthy@google.com>,
	Shailend Chand <shailend@google.com>,
	Willem de  Bruijn <willemb@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Junfeng Guo <junfeng.guo@intel.com>,
	Ziwei Xiao <ziweixiao@google.com>,
	Jeroen de Borst <jeroendb@google.com>,
	linux-kernel@vger.kernel.org, kory.maincent@bootlin.com,
	andrew@lunn.ch, richardcochran@gmail.com
Subject: Re: [PATCH net-next] gve: Correctly report software timestamping capabilities
Date: Wed, 10 Apr 2024 06:19:28 -0700	[thread overview]
Message-ID: <20240410061928.712ff9a3@kernel.org> (raw)
In-Reply-To: <87jzl5akh5.fsf@nvidia.com>

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?

  reply	other threads:[~2024-04-10 13:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08 18:09 [PATCH net-next] gve: Correctly report software timestamping capabilities John Fraker
2024-04-09 14:29 ` Willem de Bruijn
2024-04-10  0:28   ` Jakub Kicinski
2024-04-10  4:40     ` Rahul Rameshbabu
2024-04-10 13:19       ` Jakub Kicinski [this message]
2024-04-10 19:31         ` Willem de Bruijn
2024-04-11  0:40           ` Rahul Rameshbabu
2024-04-11  1:36             ` Willem de Bruijn
2024-04-10  0:26 ` Jakub Kicinski
2024-04-11  3:22   ` Willem de Bruijn
2024-04-11 19:37     ` John Fraker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240410061928.712ff9a3@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hramamurthy@google.com \
    --cc=jeroendb@google.com \
    --cc=jfraker@google.com \
    --cc=junfeng.guo@intel.com \
    --cc=kory.maincent@bootlin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pkaligineedi@google.com \
    --cc=richardcochran@gmail.com \
    --cc=rrameshbabu@nvidia.com \
    --cc=shailend@google.com \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=ziweixiao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.