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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20201203182908.1d25ea3f@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date:   Thu, 3 Dec 2020 18:29:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeedm@...dia.com>
Cc:     "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        "Eran Ben Elisha" <eranbe@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [net-next V2 08/15] net/mlx5e: Add TX PTP port object support

On Wed, 2 Dec 2020 20:21:01 -0800 Saeed Mahameed wrote:
> Add TX PTP port object support for better TX timestamping accuracy.
> Currently, driver supports CQE based TX port timestamp. Device
> also offers TX port timestamp, which has less jitter and better
> reflects the actual time of a packet's transmit.

How much better is it?

Is the new implementation is standard compliant or just a "better
guess"?

> Define new driver layout called ptpsq, on which driver will create
> SQs that will support TX port timestamp for their transmitted packets.
> Driver to identify PTP TX skbs and steer them to these dedicated SQs
> as part of the select queue ndo.
> 
> Driver to hold ptpsq per TC and report them at
> netif_set_real_num_tx_queues().
> 
> Add support for all needed functionality in order to xmit and poll
> completions received via ptpsq.
> 
> Add ptpsq to the TX reporter recover, diagnose and dump methods.
> 
> Creation of ptpsqs is disabled by default, and can be enabled via
> tx_port_ts private flag.

This flag is pretty bad user experience.

> This patch steer all timestamp related packets to a ptpsq, but it
> does not open the port timestamp support for it. The support will
> be added in the following patch.

Overall I'm a little shocked by this, let me sleep on it :)

More info on the trade offs and considerations which led to the
implementation would be useful.