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

On Tue, May 04, 2021 at 09:08:00PM +0200, Michael Walle wrote:

quoted

quoted

quoted

quoted

As explained in another mail in this thread, all queues are marked as
scheduled. So this is actually a no-op, correct? It doesn't matter if
it set or not set for now. Dunno why we even care for this bit then.

It matters because ALWAYS_GUARD_BAND_SCH_Q reduces the available
throughput when set.

Ahh, I see now. All queues are "scheduled" but the guard band only
applies
for "non-scheduled" -> "scheduled" transitions. So the guard band is
never
applied, right? Is that really what we want?

Xiaoliang explained that yes, this is what we want. If the end user
wants a guard band they can explicitly add a "sched-entry 00" in the
tc-taprio config.

You're disabling the guard band, then. I figured, but isn't that
suprising for the user? Who else implements taprio? Do they do it in the
same way? I mean this behavior is passed right to the userspace and have
a direct impact on how it is configured. Of course a user can add it
manually, but I'm not sure that is what we want here. At least it needs
to be documented somewhere. Or maybe it should be a switchable option.

Consider the following:
sched-entry S 01 25000
sched-entry S fe 175000
basetime 0

Doesn't guarantee, that queue 0 is available at the beginning of
the cycle, in the worst case it takes up to
<begin of cycle> + ~12.5us until the frame makes it through (given
gigabit and 1518b frames).

Btw. there are also other implementations which don't need a guard
band (because they are store-and-forward and cound the remaining
bytes). So yes, using a guard band and scheduling is degrading the
performance.

What is surprising for the user, and I mentioned this already in another
thread on this patch, is that the Felix switch overruns the time gate (a
packet taking 2 us to transmit will start transmission even if there is
only 1 us left of its time slot, delaying the packets from the next time
slot by 1 us). I guess that this is why the ALWAYS_GUARD_BAND_SCH_Q bit
exists, as a way to avoid these overruns, but it is a bit of a poor tool
for that job. Anyway, right now we disable it and live with the overruns.

FWIW, the ENETC does not overrun the time gate, the SJA1105 does. You
can't really tell just by looking at the driver code, just by testing.
It's a bit of a crapshoot.

quoted

Sorry, I don't understand what you mean to say here.

I doubt that ALWAYS_GUARD_BAND_SCH_Q is a per-port setting. But that is
only a guess. One would have to check with the IP vendor.

Probably not, but I'm not sure that this is relevant one way or another,
as the driver unconditionally clears it regardless of port (or unconditionally
set it, before Xiaoliang's patch).

quoted

quoted

quoted

May I know what drew your attention to this patch? Is there something
wrong?

See private mail.

Responded. I'm really curious if this change makes any difference at all
to your use case.