Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption
Date: Tue, 19 May 2020 08:32:40 -0700	[thread overview]
Message-ID: <87v9ksndnr.fsf@intel.com> (raw)
In-Reply-To: <b33e582f-e0e6-467a-636a-674322108855@ti.com>

Murali Karicheri <m-karicheri2@ti.com> 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.

>
> 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.


Cheers,
-- 
Vinicius

  reply	other threads:[~2020-05-19 15:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16  1:29 [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption Vinicius Costa Gomes
2020-05-16  1:29 ` [Intel-wired-lan] [next-queue RFC 1/4] ethtool: Add support for configuring " Vinicius Costa Gomes
2020-05-19 15:27   ` Murali Karicheri
2020-05-16  1:29 ` [Intel-wired-lan] [next-queue RFC 2/4] ethtool: Add support for configuring frame preemption via netlink Vinicius Costa Gomes
2020-05-16  1:29 ` [Intel-wired-lan] [next-queue RFC 3/4] igc: Add support for configuring frame preemption Vinicius Costa Gomes
2020-05-19 16:36   ` Murali Karicheri
2020-05-16  1:29 ` [Intel-wired-lan] [next-queue RFC 4/4] igc: Add support for exposing frame preemption stats registers Vinicius Costa Gomes
2020-05-20 12:50   ` Murali Karicheri
2020-05-16  9:33 ` [Intel-wired-lan] [next-queue RFC 0/4] ethtool: Add support for frame preemption Michal Kubecek
2020-05-18 19:34   ` Vinicius Costa Gomes
2020-05-19 22:40     ` Andre Guedes
2020-05-19 22:53       ` Vinicius Costa Gomes
2020-05-16 20:37 ` David Miller
2020-05-16 21:03   ` Vladimir Oltean
2020-05-16 22:19     ` David Miller
2020-05-17 10:51       ` Vladimir Oltean
2020-05-17 18:45         ` Andrew Lunn
2020-05-17 19:04           ` Vladimir Oltean
2020-05-18 19:05       ` Vinicius Costa Gomes
2020-05-18 20:56         ` Jakub Kicinski
2020-05-18 22:06           ` Vinicius Costa Gomes
2020-05-18 22:22             ` Jakub Kicinski
2020-05-18 23:05               ` Vinicius Costa Gomes
2020-05-18 23:09                 ` Jakub Kicinski
2020-05-20 21:42                   ` Andre Guedes
2020-05-20 22:35                     ` Vinicius Costa Gomes
2020-05-19 16:34             ` Murali Karicheri
2020-05-19 17:49               ` Vinicius Costa Gomes
2020-05-19 14:53 ` Murali Karicheri
2020-05-19 15:32   ` Vinicius Costa Gomes [this message]
2020-05-19 16:11     ` Murali Karicheri
2020-05-19 22:39 ` Andre Guedes
2020-05-19 23:37   ` Vinicius Costa Gomes
2020-05-20 12:47     ` Murali Karicheri
2020-05-20 12:52     ` Joergen Andreasen
2020-05-20 21:32       ` Vinicius Costa Gomes
  -- strict thread matches above, loose matches on Subject: below --
2020-05-19  9:10 Po Liu
2020-05-19 16:43 ` Vinicius Costa Gomes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9ksndnr.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox