netdev - Re: [PATCH v8 net-next 5/5] net: ena: Add PHC documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0294be1a-5530-435a-9717-983f61b94fcf@lunn.ch>
Date: Mon, 7 Apr 2025 16:02:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Arinzon, David" <darinzon@...zon.com>
Cc: Leon Romanovsky <leon@...n.nu>, Jakub Kicinski <kuba@...nel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Richard Cochran <richardcochran@...il.com>,
	"Woodhouse, David" <dwmw@...zon.co.uk>,
	"Machulsky, Zorik" <zorik@...zon.com>,
	"Matushevsky, Alexander" <matua@...zon.com>,
	"Bshara, Saeed" <saeedb@...zon.com>,
	"Wilson, Matt" <msw@...zon.com>,
	"Liguori, Anthony" <aliguori@...zon.com>,
	"Bshara, Nafea" <nafea@...zon.com>,
	"Schmeilin, Evgeny" <evgenys@...zon.com>,
	"Belgazal, Netanel" <netanel@...zon.com>,
	"Saidi, Ali" <alisaidi@...zon.com>,
	"Herrenschmidt, Benjamin" <benh@...zon.com>,
	"Kiyanovski, Arthur" <akiyano@...zon.com>,
	"Dagan, Noam" <ndagan@...zon.com>,
	"Bernstein, Amit" <amitbern@...zon.com>,
	"Allen, Neil" <shayagr@...zon.com>,
	"Ostrovsky, Evgeny" <evostrov@...zon.com>,
	"Tabachnik, Ofir" <ofirt@...zon.com>,
	"Machnikowski, Maciek" <maciek@...hnikowski.net>,
	Rahul Rameshbabu <rrameshbabu@...dia.com>,
	Gal Pressman <gal@...dia.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Subject: Re: [PATCH v8 net-next 5/5] net: ena: Add PHC documentation

On Mon, Apr 07, 2025 at 07:01:46AM +0000, Arinzon, David wrote:
> > >> > I think the sysfs control is the best option here.
> > >>
> > >> Actually, it occurs to me that the best option is probably a module
> > >> parameter. If you have to take the network down and up to change the
> > >> mode, why not just unload and reload the module?
> > >
> > > We have something called devlink params, which support "configuration
> > > modes" (= what level of reset is required to activate the new setting).
> > > Maybe devlink param with cmode of "driver init" would be the best fit?
> > 
> > I had same feeling when I wrote my auxbus response. There is no reason to
> > believe that ptp enable/disable knob won't be usable by other drivers
> > 
> > It's universally usable, just not related to netdev sysfs layout.
> > 
> > Thanks
> > 
> > >
> > > Module params are annoying because they are scoped to code / module
> > > not instances of the device.
> 
> Hi Jakub,
> 
> Thanks for suggesting the devlink params option for enable/disable, we will
> explore the option and provide a revised patchset.
> 
> Given the pushback on custom sysfs utilization, what can be the alternative for exposing 
> the PHC statistics? If `ethtool -S` is not an option, is there another framework that
> allows outputting statistics?
> We've explored devlink health reporter dump, would that be acceptable?

We seem to be going backwards and forwards between this is connected
to a netdev and it is not connected to a netdev. You have to destroy
and recreate the netdev in order to make us if it, which might just be
FUBAR design, but that is what you have. So maybe ethtool -S is an
option?

Or take a step back. Are your statistics specific to your hardware, or
generic about any PTP clock? Could you expand the PTP infrastructure
to return generic statistics? The problem being, PTP is currently
IOCTL based, so not very expandable, unlike netlink used for ethtool.

	Andrew