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: <DB8PR04MB5785A811DEB1D683E868D675F0479@DB8PR04MB5785.eurprd04.prod.outlook.com>
Date:   Wed, 21 Apr 2021 02:51:09 +0000
From:   Xiaoliang Yang <xiaoliang.yang_1@....com>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Arvid.Brodin@...n.com" <Arvid.Brodin@...n.com>,
        "m-karicheri2@...com" <m-karicheri2@...com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "vishal@...lsio.com" <vishal@...lsio.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "ivan.khoronzhuk@...aro.org" <ivan.khoronzhuk@...aro.org>,
        "andre.guedes@...ux.intel.com" <andre.guedes@...ux.intel.com>,
        "yuehaibing@...wei.com" <yuehaibing@...wei.com>,
        "allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
        "joergen.andreasen@...rochip.com" <joergen.andreasen@...rochip.com>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        Po Liu <po.liu@....com>, Mingkai Hu <mingkai.hu@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Leo Li <leoyang.li@....com>
Subject: RE: [EXT] Re: [net-next] net: dsa: felix: disable always guard band
 bit for TAS config

Hi Vladimir,

On Tue, Apr 20, 2021 at 01:30:51PM +0300, Vladimir Oltean wrote:
> One question though. I know that Felix overruns the time gate, i.e. when the time interval has any value larger than 32 ns,
> the switch port is happy to send any packet of any size, regardless of whether the duration of transmission exceeds the
> gate size or not. In doing so, it violates this requirement from IEEE 802.1Q-2018 clause 8.6.8.4 Enhancements for
> scheduled traffic:
>
> -----------------------------[ cut here ]----------------------------- 
>
> In addition to the other checks carried out by the transmission selection algorithm, a frame on a traffic class queue is not
> available for transmission [as required for tests (a) and (b) in 8.6.8] if the transmission gate is in the closed state or if
> there is insufficient time available to transmit the entirety of that frame before the next gate-close event (3.97)
> associated with that queue. A per-traffic class counter, TransmissionOverrun (12.29.1.1.2), is incremented if the
> implementation detects that a frame from a given queue is still being transmitted by the MAC when the gate-close event 
> for that queue occurs.
>
> NOTE 1—It is assumed that the implementation has knowledge of the transmission overheads that are involved in 
> transmitting a frame on a given Port and can therefore determine how long the transmission of a frame will take.
> However, there can be reasons why the frame size, and therefore the length of time needed for its transmission, is 
> unknown; for example, where cut-through is supported, or where frame preemption is supported and there is no way of 
> telling in advance how many times a given frame will be preempted before its transmission is complete. It is desirable 
> that the schedule for such traffic is designed to accommodate the intended pattern of transmission without overrunning 
> the next gate-close event for the traffic classes concerned.
> -----------------------------[ cut here ]-----------------------------
>
> Is this not the reason why the guard bands were added, to make the scheduler stop sending any frame for 1 MAX_SDU in 
> advance of the gate close event, so that it doesn't overrun the gate?

Yes, the guard band reserved a MAX_SDU time to ensure there is no packet transmission when gate close. But it's not necessary to reserve the guard band at each of GCL entry. Users can manually add guard band time at any schedule queue in their configuration if they want. For example, if they want to protect one queue, they can add a guard band GCL entry before the protect queue open. Like the note you mentioned: "It is desirable that the schedule for such traffic is designed to accommodate the intended pattern of transmission without overrunning the next gate-close event for the traffic classes concerned."

Thanks,
Xiaoliang Yang