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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 May 2020 12:11:05 -0400
From:   Murali Karicheri <>
To:     Vinicius Costa Gomes <>,
CC:     <>, <>,
        <>, <>,
Subject: Re: [next-queue RFC 0/4] ethtool: Add support for frame preemption

Hi Vinicius,

On 5/19/20 11:32 AM, Vinicius Costa Gomes wrote:
> Murali Karicheri <> writes:
>>> $ ethtool $ sudo ./ethtool --show-frame-preemption enp3s0
>>> Frame preemption settings for enp3s0:
>>> 	support: supported
>>> 	active: active
>>> 	supported queues: 0xf
>> I assume this is will be in sync with ethtool -L output which indicates
>> how many tx h/w queues present? I mean if there are 8 h/w queues,
>> supported queues will show 0xff.
> In this approach, the driver builds these bitmasks, so it's responsible
> to keep it consistent with the rest of the stuff that's exposed in
> ethtool.
>>> 	supported queues: 0xe
>>   From the command below, it appears this is the preemptible queue mask.
>> bit 0  is Q0, bit 1 Q1 and so forth. Right? In that case isn't it more
>> clear to display
>>           preemptible queues : 0xef
>> In the above Q7 is express queue and Q6-Q0 are preemptible.
> In my case, the controller I have here only has 4 queues, and Queue 0 is
> the highest priority one, and it's marked as express.

Ok. So it is up to the device driver to manage this.

>> Also there is a handshake called verify that happens which initiated
>> by the h/w to check the capability of peer. It looks like
>> not all vendor's hardware supports it and good to have it displayed
>> something like
>>           Verify supported/{not supported}
>> If Verify is supported, FPE is enabled only if it succeeds. So may be
>> good to show a status of Verify if it is supported something like
>>           Verify success/Failed
>>> 	minimum fragment size: 68
>>> $ ethtool --set-frame-preemption enp3s0 fp on min-frag-size 68 preemptible-queues-mask 0xe
>>> This is a RFC because I wanted to have feedback on some points:
>>>     - The parameters added are enough for the hardware I have, is it
>>>       enough in general?
>> As described above, it would be good to add an optional parameter for
>> verify
>> ethtool --set-frame-preemption enp3s0 fp on min-frag-size 68
>> preemptible-queues-mask 0xe verify on
> The hardware I have do not support this, but this makes sense.

I can work to support this for TI AM65 CPSW once a formal patch is
available. AM65 CPSW supports Verify as an optional feature. H/w works
also in manual mode where it is assumed that it is connected to a
IET FPE capable partner, but can't do Verify.

Thanks for sending the RFC.


> Cheers,

Murali Karicheri
Texas Instruments

Powered by blists - more mailing lists