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: <Ye5xN6sQvsfX1lmn@localhost>
Date:   Mon, 24 Jan 2022 10:28:23 +0100
From:   Miroslav Lichvar <mlichvar@...hat.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        Andrew Lunn <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Jakub Kicinski <kuba@...nel.org>,
        Joakim Zhang <qiangqing.zhang@....com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping
 layer be selectable.

On Fri, Jan 21, 2022 at 07:28:20AM -0800, Richard Cochran wrote:
> On Fri, Jan 21, 2022 at 02:50:36PM +0000, Vladimir Oltean wrote:
> > So as I mentioned earlier, the use case would be hardware performance
> > testing and diagnosing. You may consider that as not that important, but
> > this is basically what I had to do for several months, and even wrote
> > a program for that, that collects packet timestamps at all possible points.
> 
> This is not possible without making a brand new CMSG to accommodate
> time stamps from all the various layers.

FWIW, scm_timestamping has three fields and the middle one no longer
seems to be used. If a new socket/timestamping option enabled all
three (SW, MAC, PHY) timestamps in the cmsg, I think that would be a
nice feature.

There are applications that receive both SW and HW timestamps in order
to fall back to SW when a HW timestamp glitched or is missing. This
could be extended to three levels with MAC and PHY timestamps.

> That is completely out of scope for this series.
> 
> The only practical use case of this series is to switch from PHY back to MAC.

>From an admin point of view, it makes sense to me to have an option to
disable PHY timestamps for the whole device if there are issues with
it. For debugging and applications, it would be nice to have an option
to get all of them at the same time.

-- 
Miroslav Lichvar

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ