All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Max Georgiev <glipus@gmail.com>,
	kory.maincent@bootlin.com, netdev@vger.kernel.org,
	maxime.chevallier@bootlin.com
Subject: Re: [PATCH net-next RFC] Add NDOs for hardware timestamp get/set
Date: Sat, 1 Apr 2023 12:24:50 -0700	[thread overview]
Message-ID: <20230401122450.0fd88313@kernel.org> (raw)
In-Reply-To: <20230401191215.tvveoi3lkawgg6g4@skbuf>

On Sat, 1 Apr 2023 22:12:15 +0300 Vladimir Oltean wrote:
> Actually, and here is the problem, DSA will want to see the timestamping
> request with the new code path too, not just with the legacy one.
> But, in this form, the dsa_ndo_eth_ioctl() -> dsa_master_ioctl() code
> path wants to do one of two things: it either denies the configuration,
> or passes it further, unchanged, to the master's netdev_ops->ndo_eth_ioctl().
> 
> By being written around the legacy ndo_eth_ioctl(), dsa_ndo_eth_ioctl()
> places a requirement which conflicts with any attempt to convert any
> kernel driver to the new API, because basically any net device can serve
> as a DSA master, and simply put, DSA wants to see timestamping requests
> to the DSA master, old or new API.
> 
> The only "useful" piece of logic from dsa_master_ioctl() is to deny the
> hwtstamp_set operation in some cases, so it's clear that it's useless
> for dsa_master_ioctl() to have to call the master's netdev_ops->ndo_eth_ioctl()
> when dev_eth_ioctl() already would have done it anyway.

So the current patch can only convert drivers which can't be a DSA
master :( (realistically any big iron NIC for example)
It should be relatively easy to plumb both the ifr and the in-kernel
config thru all the DSA APIs and have it call the right helper, too,
tho? SMOC?

> I can make dsa_ndo_eth_ioctl() disappear and replace it with a netdev
> notifier as per this patch:
> https://lore.kernel.org/netdev/20220317225035.3475538-1-vladimir.oltean@nxp.com/
> 
> My understanding of Jakub's objection is that the scope of the
> NETDEV_ETH_IOCTL is too wide, and as such, it would need to change to
> something like NETDEV_HWTSTAMP_SET. I can make that change if that is
> the only objection, and resubmit that as preparation work for the
> ndo_hwtstamp_set() effort.

My objection to the IOCTL is that there's a lot of boilerplate that 
the drivers have to copy and that it makes it harder to do meaningful
work in the core.

  reply	other threads:[~2023-04-01 19:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-31  4:56 [PATCH net-next RFC] Add NDOs for hardware timestamp get/set Maxim Georgiev
2023-03-31  5:35 ` Jakub Kicinski
2023-03-31 17:51   ` Max Georgiev
2023-03-31 18:10     ` Jakub Kicinski
2023-04-01 18:16       ` Vladimir Oltean
2023-04-01 19:12       ` Vladimir Oltean
2023-04-01 19:24         ` Jakub Kicinski [this message]
2023-04-01 19:30           ` Vladimir Oltean
2023-04-01 20:18           ` Vladimir Oltean
2023-04-02 14:28             ` Max Georgiev
2023-04-02 16:56               ` Vladimir Oltean
2023-04-01 16:08   ` Vladimir Oltean
2023-04-01 17:55     ` Jakub Kicinski
2023-04-01 18:20       ` Vladimir Oltean
2023-04-01 18:22         ` Vladimir Oltean
2023-04-01 19:14         ` Jakub Kicinski
2023-04-01 19:19           ` Vladimir Oltean

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=20230401122450.0fd88313@kernel.org \
    --to=kuba@kernel.org \
    --cc=glipus@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=vladimir.oltean@nxp.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.