On 5/18/20 6:06 PM, Vinicius Costa Gomes wrote:
Hi,
Jakub Kicinski <k...@kernel.org> writes:
Please take a look at the example from the cover letter:
$ ethtool $ sudo ./ethtool --show-frame-preemption
enp3s0 Frame preemption settings for enp3s0:
support: supported
active: active
supported queues: 0xf
supported queues: 0xe
minimum fragment size: 68
Reading this I have no idea what 0xe is. I have to go and query TC API
to see what priorities and queues that will be. Which IMHO is a strong
argument that this information belongs there in the first place.
That was the (only?) strong argument in favor of having frame preemption
in the TC side when this was last discussed.
We can have a hybrid solution, we can move the express/preemptible per
queue map to mqprio/taprio/whatever. And have the more specific
configuration knobs, minimum fragment size, etc, in ethtool.
Isn't this a pure h/w feature? FPE is implemented at L2 and involves
fragments that are only seen by h/w and never at Linux network core
unlike IP fragments and is transparent to network stack. However it
enhances priority handling at h/w to the next level by pre-empting
existing lower priority traffic to give way to express queue traffic
and improve latency. So everything happens in h/w. So ethtool makes
perfect sense here as it is a queue configuration. I agree with Vinicius
and Vladmir to support this in ethtool instead of TC.
Murali
What do you think?
Cheers,
--
Murali Karicheri
Texas Instruments
