netdev - Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping layer be selectable.

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]

Date: Tue, 16 May 2023 12:28:18 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Köry Maincent <kory.maincent@...tlin.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
 glipus@...il.com, maxime.chevallier@...tlin.com, vadim.fedorenko@...ux.dev,
 richardcochran@...il.com, gerhard@...leder-embedded.com,
 thomas.petazzoni@...tlin.com, linux@...linux.org.uk
Subject: Re: [PATCH net-next RFC v4 4/5] net: Let the active time stamping
 layer be selectable.

On Mon, 15 May 2023 11:04:32 +0200 Köry Maincent wrote:
> > I see, so there is a legit reason to abort. 
> > 
> > We could use one of the high error codes, then, to signal 
> > the "I didn't care, please carry on to the PHY" condition?
> > -ENOTSUPP?
> > 
> > I guess we can add a separate "please configure traps for PTP/NTP" 
> > NDO, if you prefer. Mostly an implementation detail.  
> 
> I am not as expert as you on the network stack therefore I am trying to follow
> and understand all the remarks. Please correct me if I say something wrong. It
> is interesting to understand all the complications that these changes bring.
> 
> To summary, what do you think is preferable for this patch series?
> - New ops for TS as suggested by Russell.
> 
> - Continue on this implementation and check that Vladimir A,B and C cases are
>   handled. Which imply, if I understand well, find a good way to deal with PTP
>   change trap (bit or new ndo ops), convert most drivers from IOCTL to NDO
>   beforehand. 
> 
> - Add MAC-DMA TS? It think it is needed as MAC-DMA TS seems already used and
>   different from simple MAC TS in term of quality, as described by Jakub.

These aren't really disjoint alternatives, we need MAC-DMA TS and we
need a way to direct all TS requests to the MAC driver. Whether we do
it via an NDO, flags or new ops is kind of up to you. Question of
aesthetics.

Perhaps to move forward it'd be good to rev the patches, and address
the feedback which is clear?