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 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:   Sat, 5 Dec 2020 00:55:30 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Eran Ben Elisha <eranbe@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>,
        Richard Cochran <richardcochran@...il.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [net-next V2 08/15] net/mlx5e: Add TX PTP port object support

Hi Jakub,

On Fri, Dec 04, 2020 at 02:52:40PM -0800, Jakub Kicinski wrote:
> On Fri, 04 Dec 2020 13:57:49 -0800 Saeed Mahameed wrote:
> > > Why not use the PTP classification helpers we already have?
> >
> > do you mean ptp_parse_header() or the ebpf prog ?
> > We use skb_flow_dissect() which should be simple enough.
>
> Not sure which exact one TBH, I just know we have helpers for this,
> so if we don't use them it'd be good to at least justify why.
>
> Maybe someone with more practical knowledge here can chime in with
> a recommendation for a helper to find PTP frames on TX?

ptp_classify_raw is optimized to identify PTP event messages (the only
ones that need to be timestamped as far as the protocol is concerned).
PTP general messages (Follow-Up, Delay_Resp, Announce etc) will return
PTP_CLASS_NONE from ptp_classify_raw.

But maybe there is an even better way, since this is on the TX path,
maybe the .ndo_select_queue operation can simply look at
	skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP
when deciding whether to send it to the "good" queue or not. This has
the advantage of being less expensive than any sort of frame classification.

Nonetheless, some tests would need to be run. In theory, practice and
theory are the same, whereas in practice they aren't.