From: Alexander Duyck <alexander.duyck@gmail.com>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: Amritha Nambiar <amritha.nambiar@intel.com>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
Date: Sun, 21 May 2017 15:35:13 -0700 [thread overview]
Message-ID: <CAKgT0Ue6tDOE8L4thktyje-erGkVMmtO7zyp0FRgmRPYOppjQA@mail.gmail.com> (raw)
In-Reply-To: <CAJ3xEMjTDW7sQ5CFmTyR5xMpin_WFFQg-S8imWMBpXWuS1zvVw@mail.gmail.com>
On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
> <amritha.nambiar@intel.com> wrote:
>> The following series introduces a new harware offload mode in tc/mqprio
>
> Wait, we have already a HW QoS model introduced by John F and Co
> couple of years ago, right?
I assume you are referring to the ETS portion of DCBX? If so then yes
we have something there, but there is a fairly high level of
complexity and dependencies in order to enable that. What we have in
mind doesn't really fit with DCBX and the problem is the spec calls
out that you really have to have support for DCBX in order to make use
of ETS. What we are trying to do here is provide a lightweight way of
doing this configuration similar to how mqprio was already providing a
lightweight way of enabling multiple traffic classes.
> Please elaborate in few sentence if you are extending it/replacing it,
> why we want to do that and what are the implications on existing
> applications UAPI wise.
This is meant to be an extension of the existing structure. It can be
ignored by the driver and instead only have the basic hw offload
supported. In such a case the command will still return success but
any rate limits and queue configuration can be ignored. In the case of
the current implementation the queue configuration was already being
ignored so we opted to re-purpose the "hw" flag so that if you pass a
value greater than 1 and the driver doesn't recognize the value it has
the option to just ignore the extra bits it doesn't recognize and
return 1 as it did before for the hw flag in mqprio.
> Below you just say in the new mode Qos is configured with knobs XYZ --
> this is way not enough
Can you clarify what you are asking for here? Amritha included an
example in patch 1 of a command line that enabled 2 traffic classes
with rate limits. Is there something more specific you are looking
for?
Thanks.
- Alex
next prev parent reply other threads:[~2017-05-21 22:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-20 0:58 [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio Amritha Nambiar
2017-05-19 22:30 ` [Intel-wired-lan] " John Fastabend
2017-05-20 0:58 ` [PATCH 1/4] [next-queue]net: mqprio: Introduce new hardware offload mode in mqprio for offloading full TC configurations Amritha Nambiar
2017-05-24 21:59 ` [Intel-wired-lan] " Alexander Duyck
2017-05-20 0:58 ` [PATCH 2/4] [next-queue]net: i40e: Add infrastructure for queue channel support with the TCs and queue configurations offloaded via mqprio scheduler Amritha Nambiar
2017-05-24 21:45 ` [Intel-wired-lan] " Alexander Duyck
2017-05-20 0:58 ` [PATCH 3/4] [next-queue]net: i40e: Enable mqprio full offload mode in the i40e driver for configuring TCs and queue mapping Amritha Nambiar
2017-05-24 22:05 ` [Intel-wired-lan] " Alexander Duyck
2017-05-20 0:58 ` [PATCH 4/4] [next-queue]net: i40e: Add support to set max bandwidth rates for TCs offloaded via tc/mqprio Amritha Nambiar
2017-05-20 21:15 ` [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio Or Gerlitz
2017-05-21 22:35 ` Alexander Duyck [this message]
2017-05-22 3:25 ` [Intel-wired-lan] " Or Gerlitz
2017-05-22 16:40 ` Duyck, Alexander H
2017-05-22 19:31 ` Jeff Kirsher
2017-07-21 9:42 ` Richard Cochran
2017-07-26 18:18 ` Nambiar, Amritha
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=CAKgT0Ue6tDOE8L4thktyje-erGkVMmtO7zyp0FRgmRPYOppjQA@mail.gmail.com \
--to=alexander.duyck@gmail.com \
--cc=amritha.nambiar@intel.com \
--cc=gerlitz.or@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).