linux-kernel - Re: Design issue in DSA RX timestamping (Was "Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can

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] [day] [month] [year] [list]

Date:   Tue, 19 Nov 2019 06:03:22 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: Design issue in DSA RX timestamping (Was "Re: [PATCH net-next
 3/5] net: dsa: mv88e6xxx: Let taggers specify a can_timestamp function")

On Tue, Nov 19, 2019 at 01:35:14PM +0200, Vladimir Oltean wrote:
> - DSA doesn't let drivers to select which frames should be
> timestamped. It knows better.

It time stamps the event frames.
 
> - To be precise, it runs the PTP BPF classifier and filters only the
> SYNC (but not FOLLOW-UP) messages. In principle I agree, the FOLLOW-UP
> frames are general messages and don't need to be timestamped for the
> PTP protocol to work. But by that logic, the HWTSTAMP_FILTER_ALL
> rx_filter shouldn't exist?

FILTER_ALL means all event frames on all transports.  It has nothing
to do with event messages.

> - Because it treats SYNC and FOLLOW-UP frames differently on the RX
> path, it gives them a chance to get reordered. It doesn't give the
> driver a chance to avoid the reordering.

The re-ordering will occur no matter what.  Think about the UDP/IPv4
transport.  The event and general messages are on different ports!
The user space PTP must deal with message re-ordering.


> - Without fully understanding what happens, I tried to propose better
> logic for recovering reordered SYNC/FOLLOW-UP pairs at the application
> level in linuxptp [1]. Needless to say, the consensus was to fix the
> kernel. So here we are.
> 
> [1] https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/thread/20190928123414.9422-1-olteanv%40gmail.com/#msg36773629

There was no consensus to fix the kernel.  The kernel is fine.  Your
hardware is too slow to keep up with the very high message rate of the
telecom profiles.  Here are a few quotes from that discussion:

   ---
   Are you saying in a local network it's expected that a PTP slave
   receives the follow-up message one or more sync intervals after the
   corresponding sync message, e.g. a delay of 1 second with the default
   sync interval?
   
   I'd not consider such network to be suitable for PTP.
   ---
   I think it's expected that two messages sent within few microseconds or
   milliseconds can be received in a wrong order and PTP slaves need to
   handle that. But it's not expected that a message will be delayed so
   much that it will be received after a message that was sent one or
   more sync intervals later.
   ---
   I'd not expect to receive a follow-up message 30 milliseconds
   after the corresponding sync message. If the difference was getting to
   the millisecond range, I'd be worried that the network is so
   overloaded or misconfigured that it might drop some PTP messages.
   ---

Thanks,
Richard