netdev - Re: [PATCH net-next] net: ethtool: allow MAC drivers to override ethtool get_ts

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]

Date:   Thu, 21 Jan 2021 19:55:34 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: ethtool: allow MAC drivers to override
 ethtool get_ts_info

On Thu, Jan 21, 2021 at 09:03:47AM -0800, Richard Cochran wrote:
> On Thu, Jan 21, 2021 at 05:22:37PM +0100, Andrew Lunn wrote:
> 
> > There is a growing interesting in PTP, the number of drivers keeps
> > going up. The likelihood of MAC/PHY combination having two
> > timestamping sources is growing all the time. So the stack needs to
> > change to support the selection of the timestamp source.
> 
> Fine, but How should the support look like?
> 
> - New/extended time stamping API that delivers multiple time stamps?
> 
> - sysctl to select MAC/PHY preference at run time globally?
> 
> - per-interface ethtool control?
> 
> - per-socket control?  (probably not feasible, but heh)
> 
> Back of the napkin design ideas appreciated!

Do you know of any realistic uses cases for using two time stampers
for the same netdev? If we can eliminate that, then it is down to
selecting which one to use. And i would say, the selection needs to be
per netdev.

I don't know the ptp subsystem very well, but it seems like
ptp_clock_register() does not know which netdev the device is being
registered against. Is it guaranteed that parent is actual a MAC?
Seems like adding a netdev member to that call could be good, so the
core knows what stampers are available per netdev. It then becomes
possible to enumerate the stampers associated to a netdev, and to
select one to be used.

get_ts_info() is a problem because the MAC directly implements it. It
seems like you need all kAPI calls to go into the ptp core. It can
then call into the selected driver. So ptp_clock_info might need
additional methods, get_ts_info() for example.

	   Andrew