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

[Vladimir Oltean]

On Tue, Apr 20, 2021 at 01:30:51PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 20, 2021 at 10:28:45AM +0000, Xiaoliang Yang wrote:
> > Hi Vladimir,
> > 
> > On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
> > >
> > > On Tue, Apr 20, 2021 at 03:06:40AM +0000, Xiaoliang Yang wrote:
> > >> Hi Vladimir.
> > >>
> > >> On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
> > >> >
> > >> >What is a scheduled queue? When time-aware scheduling is enabled on 
> > >> >the port, why are some queues scheduled and some not?
> > >>
> > >> The felix vsc9959 device can set SCH_TRAFFIC_QUEUES field bits to 
> > >> define which queue is scheduled. Only the set queues serves schedule 
> > >> traffic. In this driver we set all 8 queues to be scheduled in 
> > >> default, so all the traffic are schedule queues to schedule queue.
> > >
> > > I understand this, what I don't really understand is the distinction
> > > that the switch makes between 'scheduled' and 'non-scheduled'
> > > traffic.  What else does this distinction affect, apart from the
> > > guard bands added implicitly here? The tc-taprio qdisc has no notion
> > > of 'scheduled' queues, all queues are 'scheduled'. Do we ever need
> > > to set the scheduled queues mask to something other than 0xff? If
> > > so, when and why?
> > 
> > Yes, it seems only affect the guard band. If disabling always guard
> > band bit, we can use SCH_TRAFFIC_QUEUES to determine which queue is
> > non-scheduled queue. Only the non-scheduled queue traffic will reserve
> > the guard band. But tc-taprio qdisc cannot set scheduled or
> > non-scheduled queue now. Adding this feature can be discussed in
> > future. 
> > 
> > It is not reasonable to add guardband in each queue traffic in
> > default, so I disable the always guard band bit for TAS config.
> 
> Ok, if true, then it makes sense to disable ALWAYS_GUARD_BAND_SCH_Q.

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?