Date:   Thu, 06 May 2021 16:20:59 +0200
From:   Michael Walle <michael@...le.cc>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        UNGLinuxDriver@...rochip.com, alexandre.belloni@...tlin.com,
        allan.nielsen@...rochip.com,
        Claudiu Manoil <claudiu.manoil@....com>, davem@...emloft.net,
        idosch@...lanox.com, joergen.andreasen@...rochip.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        Po Liu <po.liu@....com>, vinicius.gomes@...el.com
Subject: Re: [net-next] net: dsa: felix: disable always guard band bit for TAS
 config

Am 2021-05-06 15:50, schrieb Vladimir Oltean:
> On Thu, May 06, 2021 at 03:25:07PM +0200, Michael Walle wrote:
>> Am 2021-05-04 23:33, schrieb Vladimir Oltean:
>> > [ trimmed the CC list, as this is most likely spam for most people ]
>> >
>> > On Tue, May 04, 2021 at 10:23:11PM +0200, Michael Walle wrote:
[..]

>> > With the ALWAYS_GUARD_BAND_SCH_Q bit, there will be hiccups in packet
>> > transmission for TC 7. For example, at the end of every time slot,
>> > the hardware will insert a guard band for TC 7 because there is a
>> > scheduled-queue-to-scheduled-queue transition, and it has been told to
>> > do that. But a packet with TC 7 should be transmitted at any time,
>> > because that's what we told the port to do!
>> >
>> > Alternatively, we could tell the switch that TC 7 is "scheduled", and
>> > the others are "not scheduled". Then it would implement the guard band
>> > at the end of TCs 0-6, but it wouldn't for packets sent in TC 7. But
>> > when you look at the overall schedule I described above, it kinds looks
>> > like TCs 0-6 are the ones that are "scheduled" and TC 7 looks like the
>> > one which isn't "scheduled" but can send at any time it pleases.
>> >
>> > Odd, just odd. It's clear that someone had something in mind, it's just
>> > not clear what. I would actually appreciate if somebody from Microchip
>> > could chime in and say "no, you're wrong", and then explain.
>> 
>> If I had to make a bet, the distinction between "scheduled" and
>> "non-scheduled" is there to have more control for some traffic classes
>> you trust and where you can engineer the traffic, so you don't really
>> need the guard band and between arbitrary traffic where you can't 
>> really
>> say anything about and thus need the guard band.
> 
> I still don't know if I understand properly. You mean that "scheduled"
> traffic is traffic sent synchronized with the switch's schedule, and
> which does not need guard banding at the end of its time slot because
> the sender is playing nice?

Yes exactly. If you have a low level application that might be a
reasonable optimization.

> Yes, but then, do you gain anything at all by disabling that guard band
> and allowing the sender to overrun if they want to? I still don't see
> why overruns are permitted by the switch in certain configurations.

First, I suspect that this shouldn't happen, because as in you words,
the sender is playing nice and won't send outside its allocated time
frame.
Second, you don't waste the (possible) deadtime for the guard band
which might make sense esp. for smaller windows.

Consider the following gate timings:

(1) gate open event
(2)-(3) guard band
(3) gate close event

       (1)                 (2)      (3)
        _________ ... ______________
______|                    |_______|________


And the following timings for a frame:

(A)           ___... ___
_____________|          |___________________

(B)                   ___... ___
_____________________|          |___________

(C)                          ____
____________________________|    |__________


(A) and (B) can be send if there is a guard band, (C) can only
be send if there is no guard band. But in the case of (C) you
have to trust the sender to stop sending before reaching (3).
For (B) you don't have to trust the sender because the end of the
frame cannot be later than (3).

-michael

Powered by blists - more mailing lists