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:   Thu, 21 May 2020 09:18:44 +0000
From:   Mark Starovoytov <>
To:     Jakub Kicinski <>
CC:     "" <>,
        "David S . Miller" <>,
        Dmitry Bezrukov <>,
        Igor Russkikh <>
Subject: RE: [EXT] Re: [PATCH net-next 03/12] net: atlantic: changes for
 multi-TC support

Hi Jakub,

> > In the first generation of our hardware (A1), a whole traffic class is
> > consumed for PTP handling in FW (FW uses it to send the ptp data and
> > to send back timestamps).
> > Since this conflicts with QoS (user is unable to use the reserved
> > TC2), we suggest using module param to give the user a choice:
> > disabling PTP allows using all available TCs.
> Is there really no way to get the config automatically chosen when user sets
> up TCs or does SIOCSHWTSTAMP? It's fine to return -EOPNOTSUPP when too
> many things are enabled, but user having to set module parameters upfront
> is quite painful.

Module param is not a must have for usage, default config allows the user to use TCs and PTP features simultaneously with one major limitation: TC2 is reserved for PTP, so if the user tries to send/receive anything on TC2, if won't quite work unfortunately.
If the user wants to get "everything" from QoS/TC (e.g. use all the TCs) - he can explicitly disable the PTP via module param.

Right now we really aren't sure we can dynamically rearrange resources between QoS and PTP, since disabling/enabling PTP requires a complete HW reconfiguration unfortunately.
Even more unfortunate is the fact that we can't change the TC, which is reserved for PTP, because TC2 is hardcoded in firmware.
We would prefer to keep things as is for now, if possible. We'll discuss this with HW/FW team(s) and submit a follow-up patch, if we find a way to automatically choose the config.

Best regards,

Powered by blists - more mailing lists