netdev - Re: [net-next V2 08/15] net/mlx5e: Add TX PTP port object support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20201207124233.22540545@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date:   Mon, 7 Dec 2020 12:42:33 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        Eran Ben Elisha <eranbe@...dia.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [net-next V2 08/15] net/mlx5e: Add TX PTP port object support

On Mon, 7 Dec 2020 07:19:06 -0800 Richard Cochran wrote:
> On Mon, Dec 07, 2020 at 12:37:45AM -0800, Saeed Mahameed wrote:
> > we are not adding any new mechanism.  
> 
> Sorry, I didn't catch the beginning of this thread.  Are you proposing
> adding HWTSTAMP_TX_ON_TIME_CRITICAL_ONLY to net_tstamp.h ?
> 
> If so, then ...
> 
> > Our driver feature is and internal enhancement yes, but the suggested
> > flag is very far from indicating any internal enhancement, is actually
> > an enhancement to the current API, and is a very simple extension with
> > wide range of improvements to all layers.  
> 
> No, that would be no enhancement but rather a hack for poorly designed
> hardware.
> 
> > Our driver can optimize accuracy when this flag is set, other drivers
> > might be happy to implement it since they already have a slow hw  
> 
> Name three other drivers that would "be happy" to implement this.  Can
> you name even one other?

The behavior is not entirely dissimilar to the time stamps on
multi-layered devices (e.g. DSA switches). The time stamp can either 
be generated when the packet enters the device (current mlx5 behavior)
or when it actually egresses thru the MAC (what this set adds).

So while we could find other hardware like this if we squint hard enough
- I'm not sure how much practical use for CPU-side stamps there is in DSA.


My main concern is the user friendliness. I think there is no question
that user running ptp4l would want this mlx5 knob to be enabled. Would
we rather see a patch to ptp4l that turns per driver knob or should we
shoot for some form of an API that tells the kernel that we're
expecting ns level time accuracy? 

That's how I would phrase the dilemma here.