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:

quoted

Am 2021-05-04 23:33, schrieb Vladimir Oltean:

quoted

[ 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:

[..]

quoted

quoted

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