From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinicius Costa Gomes Date: Mon, 07 Dec 2020 14:15:25 -0800 Subject: [Intel-wired-lan] [PATCH net-next v1 6/9] igc: Add support for tuning frame preemption via ethtool In-Reply-To: <20201205100030.2e3c5dd2@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> References: <20201202045325.3254757-1-vinicius.gomes@intel.com> <20201202045325.3254757-7-vinicius.gomes@intel.com> <20201205100030.2e3c5dd2@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com> Message-ID: <87a6up1cw2.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: Jakub Kicinski 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 > > 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