Hi,

Quoting Vinicius Costa Gomes (2019-12-16 13:44:13)

quoted

quoted

Quoting Po Liu (2019-11-27 01:59:18)

quoted

User can check the feature 'tx-preemption' by command 'ethtool -k
devname'. If hareware set preemption feature. The property would be a
fixed value 'on' if hardware support the frame preemption.
Feature would show a fixed value 'off' if hardware don't support the
frame preemption.

Having some knobs in ethtool to enable when/how Frame Preemption is
advertised on the wire makes sense. I also agree that it should be "on"
by default.

Agreed. If Frame Preemption is supported by hardware and it can be
enabled/disabled, I think we should allow the user to configure it, instead of
having it fixed in 'on'.

quoted

quoted

In an early RFC series [1], we proposed a way to support frame preemption. I'm
not sure if you have considered it before implementing this other proposal
based on ethtool interface so I thought it would be a good idea to bring that up
to your attention, just in case.

 
Sorry, I didn't notice the RFC proposal. Using ethtool set the
preemption just thinking about 8021Qbu as standalone. And not limit to
the taprio if user won't set 802.1Qbv.

I see your point of using frame-preemption "standalone", I have two
ideas:

 1. add support in taprio to be configured without any schedule in the
 "full offload" mode. In practice, allowing taprio to work somewhat
 similar to (mqprio + frame-preemption), changes in the code should de
 fairly small;

 2. extend mqprio to support frame-preemption;

I'm not sure 2) is a good way to support frame preemption "standalone"
functionality since mpqrio already looks overloaded. Besides its original goal
(map traffic flows to hardware queues), it also supports different modes and
traffic shaping. I rather not add another functionality to it.

quoted

As some feedback  also want to set the MAC merge minimal fragment size
and get some more information of 802.3br.

The minimal fragment size, I guess, also makes sense to be kept in
ethtool. That is we have a sane default, and allow the user to change
this setting for special cases.

Yes, the mim fragment size is another configuration knob we should have, and it
should probably live at the same place we land the enable/disable knob.

quoted

quoted

It also aligns with the gate control operations Set-And-Hold-MAC and Set-And-
Release-MAC that can be set via 'sched-entry' (see Table 8.7 from
802.1Q-2018 for further details.

 
I am curious about Set-And-Hold-Mac via 'sched-entry'. Actually, it
could be understand as guardband by hardware preemption. MAC should
auto calculate the nano seconds before  express entry slot start to
break to two fragments. Set-And-Hold-MAC should minimal larger than
the fragment-size oct times.

Another interesting point. My first idea is that when the schedule is
offloaded to the driver and the driver detects that the "entry" width is
smaller than the fragment side, the driver could reject that schedule
with a nice error message.

My understanding is that, if HOLD operation is supported, the hardware issues
an MM_CTL.request(HOLD) at 'holdAdvance' nsecs in advance to the point where
the 'sched-entry' with Set-And-Hold-MAC starts. This comes from the description
in Table 8-7 from 802.1Q-2018.

Best regards,

Andre