[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231013175601.5mpyx7cjy6cp6sdb@skbuf>
Date: Fri, 13 Oct 2023 20:56:01 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Köry Maincent <kory.maincent@...tlin.com>,
Florian Fainelli <florian.fainelli@...adcom.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>,
Jay Vosburgh <j.vosburgh@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Horatiu Vultur <horatiu.vultur@...rochip.com>,
UNGLinuxDriver@...rochip.com,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Richard Cochran <richardcochran@...il.com>,
Radu Pirea <radu-nicolae.pirea@....nxp.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Michael Walle <michael@...le.cc>,
Jacob Keller <jacob.e.keller@...el.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>
Subject: Re: [PATCH net-next v5 08/16] net: ethtool: Add a command to expose
current time stamping layer
On Fri, Oct 13, 2023 at 10:46:06AM -0700, Jakub Kicinski wrote:
> On Fri, 13 Oct 2023 20:09:03 +0300 Vladimir Oltean wrote:
> > > > Translation between the UAPI-visible PHC index and MAC, DMA, phylib
> > > > PHY, other PHY etc can then be done by the kernel as needed.
> > >
> > > Translation by the kernel at which point?
> >
> > The gist of what I'm proposing is for the core ethtool netlink message
> > handler to get just the phc_index as an attribute. No other information
> > as to what it represents. Not that it's netdev, DMA, phylib PHY or whatnot.
> >
> > The ethtool kernel code would iterate through the stuff registered in
> > the system for the netdev, calling get_ts_info() or phy_ts_info() on it,
> > until it finds something which populates struct ethtool_ts_info ::
> > phc_index with the phc_index retrieved from netlink.
> >
> > Then, ethtool just talks with the timestamper that matched that phc_index.
> >
> > Same idea would be applied for the command that lists all timestamping
> > layers for a netdev. Check get_ts_info(), phy_ts_info(dev->phydev), and
> > can be extended in the future.
>
> I see, that could work. The user would then dig around sysfs to figure
> out which PHC has what characteristics?
Yup. /sys/class/ptp/ptp<N>/ gives you everything else you need to know
about the PHC index that's configured as the active timestamper for this
netdev. It's just that (and I need to stress this again) the
timestamping-capable DMA blocks that you're talking about, but I've
never seen, should be able to fully implement a ptp_clock, with their
own clock operations and friends.
> > > IMHO it'd indeed be clearer for the user to have an ability to read
> > > the PHC for SOF_..._DMA via ETHTOOL_MSG_TS_LIST_GET_REPLY as a separate
> > > entry, rather than e.g. assume that DMA uses the same PHC as MAC.
> >
> > I'm not really sure what you're referring to, with SOF_..._DMA.
> > The DMA, if presented as a PHC as I am proposing, would play the role of
> > the hardware timestamp provider (think SOF_TIMESTAMPING_TX_HARDWARE |
> > SOF_TIMESTAMPING_RX_HARDWARE), so there will be no driver-visible
> > special socket option flags for DMA timestamping.
>
> Each packet may want different timestamp tho, especially on Tx it
> should be fairly easy for socket to request to get "real" MAC stamps,
> while most get cheaper DMA stamps. Currently some drivers run flow
> matching to find PTP packets and automatically give them better quality
> timestamps :(
>
> Even if at the config level we use PHCs we need to translate that into
> some SKBTX_* bit, don't we?
I think Richard had something to say about that being wishful thinking:
https://lore.kernel.org/netdev/ZGw46hrpiqCVNeXS@hoboy.vegasvil.org/
On RX I'm not sure how you'd know in advance if the packet is going to
be routed to a socket that wants DMA or MAC timestamps. And having a
socket with hardware timestamps from one provider in one direction, and
another provider in the other direction, is.... not sane as a kernel API?
Powered by blists - more mailing lists