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

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

Am 2021-05-04 21:17, schrieb Vladimir Oltean:

quoted

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

quoted

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.

We are talking about the same thing here. Why is that a poor tool?

It is a poor tool because it revolves around the idea of "scheduled
queues" and "non-scheduled queues".

Consider the following tc-taprio schedule:

	sched-entry S 81 2000 # TC 7 and 0 open, all others closed
	sched-entry S 82 2000 # TC 7 and 1 open, all others closed
	sched-entry S 84 2000 # TC 7 and 2 open, all others closed
	sched-entry S 88 2000 # TC 7 and 3 open, all others closed
	sched-entry S 90 2000 # TC 7 and 4 open, all others closed
	sched-entry S a0 2000 # TC 7 and 5 open, all others closed
	sched-entry S c0 2000 # TC 7 and 6 open, all others closed

Otherwise said, traffic class 7 should be able to send any time it
wishes.

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.

quoted

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.

I was speaking of other switches, I see there is also a hirschmann
switch (hellcreek) supported in linux, for example.

Shouldn't the goal to make the configuration of the taprio qdisc
independent of the switch. If on one you'll have to manually define the
guard band by inserting dead-time scheduler entries and on another this
is already handled by the hardware (like it would be with
ALWAYS_GUARD_BAND_SCH_Q or if it doesn't need it at all), this goal
isn't met.

Also what do you expect if you use the following configuration:
sched-entry S 01 5000
sched-entry S fe <some large number>

Will queue 0 be able to send traffic? To me, with this patch, it seems
to me that this isn't always the case anymore. If there is a large packet
just sent at the end of the second cycle, the first might even be skipped
completely.
Will a user of the taprio (without knowledge of the underlying switch)
assume that it can send traffic up to ~600 bytes? I'd say yes.

Yeah, I think that if a switch overruns a packet's reserved time gate,
then the above tc-taprio schedule is as good as not having any. I didn't
say that overruns are not a problem, I just said that the ALWAYS_blah_blah
bit isn't as silver-bullet for a solution as you think.