[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a6up1cw2.fsf@intel.com>
Date: Mon, 07 Dec 2020 14:15:25 -0800
From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
jiri@...nulli.us, m-karicheri2@...com, vladimir.oltean@....com,
Jose.Abreu@...opsys.com, po.liu@....com,
intel-wired-lan@...ts.osuosl.org, anthony.l.nguyen@...el.com
Subject: Re: [PATCH net-next v1 6/9] igc: Add support for tuning frame
preemption via ethtool
Jakub Kicinski <kuba@...nel.org> writes:
> On Tue, 1 Dec 2020 20:53:22 -0800 Vinicius Costa Gomes wrote:
>> The tc subsystem sets which queues are marked as preemptible, it's the
>> role of ethtool to control more hardware specific parameters. These
>> parameters include:
>>
>> - enabling the frame preemption hardware: As enabling frame
>> preemption may have other requirements before it can be enabled, it's
>> exposed via the ethtool API;
>>
>> - mininum fragment size multiplier: expressed in usually in the form
>> of (1 + N)*64, this number indicates what's the size of the minimum
>> fragment that can be preempted.
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>
>
> WARNING: 'PREEMPTABLE' may be misspelled - perhaps 'PREEMPTIBLE'?
In the datasheet the term PREEMPTABLE is used, and when refering to
register values I chose to be consistent with the datasheet. But as the
margin for confusion is small, I can change to use "preemptible"
everywhere, no problem.
Cheers,
--
Vinicius
Powered by blists - more mailing lists