linux-kernel - RE: [EXT] Re: [net-next] net: dsa: felix: disable always guard band bit for TAS config

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: <DB8PR04MB5785C5BDBDD51401362563D6F0369@DB8PR04MB5785.eurprd04.prod.outlook.com>
Date:   Wed, 9 Jun 2021 08:06:03 +0000
From:   Xiaoliang Yang <xiaoliang.yang_1@....com>
To:     Michael Walle <michael@...le.cc>,
        Vladimir Oltean <vladimir.oltean@....com>
CC:     Vladimir Oltean <olteanv@...il.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "joergen.andreasen@...rochip.com" <joergen.andreasen@...rochip.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Po Liu <po.liu@....com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>
Subject: RE: [EXT] Re: [net-next] net: dsa: felix: disable always guard band
 bit for TAS config


On 2021-06-07 19:26, Michael Walle wrote:
> 
> Hi Vladimir, Hi Xiaoliang,
> 
> Am 2021-05-07 14:19, schrieb Vladimir Oltean:
> > Devices like Felix need the per-queue max SDU from the user - if that
> > isn's specified in the netlink message they'll have to default to the
> > interface's MTU.
> 
> Btw. just to let you and Xiaoliang know:
> 
> It appears that PORT_MAX_SDU isn't working as expected. It is used as a
> fallback if QMAXSDU_CFG_n isn't set for the guard band calculation. But it
> appears to be _not_ used for discarding any frames. E.g. if you set
> PORT_MAX_SDU to 500 the port will still happily send frames larger than 500
> bytes. (Unless of course you hit the guard band of 500 bytes). OTOH
> QMAXSDU_CFG_n works as expected, it will discard oversized frames - and
> presumly will set the guard band accordingly, I haven't tested this explicitly.
> 
> Thus, I wonder what sense PORT_MAX_SDU makes at all. If you set the guard
> band to a smaller value than the MTU, you'll also need to make sure, there will
> be no larger frames scheduled on that port.
> 
> In any case, the workaround is to set QMAXSDU_CFG_n (for all
> n=0..7) to the desired max_sdu value instead of using PORT_MAX_SDU.
> 
> It might also make sense to check with the IP supplier.
> 
> In the case anyone wants to implement that for (upstream) linux ;)
> 
> -michael

Yes, PORT_MAX_SDU is only used for guard band calculation. DEV_GMII: MAC_MAXLEN_CFG
limited the frame length accepted by the MAC. I am worried that QMAXSDU is not a universal
setting, it may just be set on Felix, so there is no suitable place to add this configuration.

Thanks,
xiaoliang