lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 May 2020 12:34:30 -0400 From: Murali Karicheri <m-karicheri2@...com> To: Vinicius Costa Gomes <vinicius.gomes@...el.com>, Jakub Kicinski <kuba@...nel.org> CC: David Miller <davem@...emloft.net>, <olteanv@...il.com>, <intel-wired-lan@...ts.osuosl.org>, <jeffrey.t.kirsher@...el.com>, <netdev@...r.kernel.org>, <vladimir.oltean@....com>, <po.liu@....com>, <Jose.Abreu@...opsys.com> Subject: Re: [next-queue RFC 0/4] ethtool: Add support for frame preemption On 5/18/20 6:06 PM, Vinicius Costa Gomes wrote: > Hi, > > Jakub Kicinski <kuba@...nel.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
Powered by blists - more mailing lists