netdev - RE: [EXT] Re: [PATCH net-next 03/12] net: atlantic: changes for multi-TC 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: <CH2PR18MB323861420A81270EC7207300D3B70@CH2PR18MB3238.namprd18.prod.outlook.com>
Date:   Thu, 21 May 2020 09:18:44 +0000
From:   Mark Starovoytov <mstarovoitov@...vell.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Dmitry Bezrukov <dbezrukov@...vell.com>,
        Igor Russkikh <irusskikh@...vell.com>
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,
Mark.