netdev - RE: [PATCH v8 net-next 4/5] net: ena: PHC stats through sysfs

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: <d3bd72e06fbb42698458c8d0ab81e6cd@amazon.com>
Date: Wed, 26 Mar 2025 15:39:14 +0000
From: "Arinzon, David" <darinzon@...zon.com>
To: Leon Romanovsky <leon@...nel.org>, Andrew Lunn <andrew@...n.ch>
CC: Jakub Kicinski <kuba@...nel.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 4/5] net: ena: PHC stats through sysfs

> > > > > > I've not been following previous versions of this patch, so i could 
> > > > > > be repeating questions already asked....
> > > > > >
> > > > > > ena_adapter represents a netdev?
> > > > > >

Yes, ena_adapter represents a netdev.

> > > > > > /* adapter specific private data structure */ struct ena_adapter {
> > > > > >     struct ena_com_dev *ena_dev;
> > > > > >     /* OS defined structs */
> > > > > >     struct net_device *netdev;
> > > > > >
> > > > > > So why are you not using the usual statistics interface for a netdev?
> > > > >
> > > > > I asked them to do this.
> > > > > They are using a PTP device as a pure clock. The netdev doesn't
> > > > > support any HW timestamping, so none of the stats are related to packets.
> > > >
> > > > So how intertwined is the PHC with the network device? Can it be
> > > > separated into a different driver? Moved into drivers/ptp?
> > > >

The PHC device is not a HW timestamping device but rather a PTP clock
that is integrated with the networking device under the same PCI device.
Enabling or disabling the ENA PHC requires reconfiguring the ENA network device.

> > > > We have already been asked if this means network drivers can be
> > > > configured via sysfs. Clearly we don't want that, so we want to
> > > > get this code out of drivers/net if possible.
> > >
> > > Is it good enough to move the relevant code to a ptp/ or phc/ dir
> > > under ...thernet/amazon/ena/ ? Moving it to ptp/ proper would
> > > require some weird abstractions, not sure if it's warranted?

We agree that relocating the PHC code to drivers/ptp would introduce unnecessary
abstractions and require synchronization mechanisms between drivers.

As with other ENA features, the PHC-related code is contained within
a dedicated file in the ethernet/amazon/ena/ directory.
Would this be an acceptable approach?

Thanks,
David

> > mtd devices have been doing this for decades. And the auxiliary bus
> > seems to be a reinvention of the mtd concepts.
> 
> No, it is not. MTD concepts are no different from standard
> register_to_other_subsystem practice, where driver stays in one subsystem
> to be used by another.
> 
> Auxillary bus is different in that it splits drivers to their logical parts and places
> them in right subsystems.
> 
> Thanks