From: Jakub Kicinski <kuba@kernel•org>
To: "Wilczynski, Michal" <michal.wilczynski@intel•com>
Cc: <netdev@vger•kernel.org>, Dima Chumak <dchumak@nvidia•com>,
"Maxim Mikityanskiy" <maximmi@nvidia•com>,
"Knitter, Konrad" <konrad.knitter@intel•com>,
Jiri Pirko <jiri@resnulli•us>,
Simon Horman <simon.horman@corigine•com>
Subject: Re: [RFC] ice: Reconfigure tx scheduling for SR-IOV
Date: Wed, 6 Jul 2022 12:56:16 -0700 [thread overview]
Message-ID: <20220706125616.0a853dfc@kernel.org> (raw)
In-Reply-To: <ec6bfee4-cf0f-c5c1-a7b3-726d7e3c6d33@intel.com>
Reminder: please don't top post on the Linux lists.
On Wed, 6 Jul 2022 12:54:12 +0200 Wilczynski, Michal wrote:
> Hi,
>
> Thank you for your e-mail.
>
> I considered using devlink-rate, and it seems like a good fit. However
> we would also
>
> need support for rate-limiting for individual queues on the VF.
> Currently we have
>
> two types of rate objects in devlink-rate: leaf and node. Would adding a
> third one - queue be accepted ?
Something along those lines. IIUC htb offload as admission control for
VF representors is not a thing today, so since devlink rate exists the
lowest amount of duplication would be teaching it about queues.
> Also we might want to add some other object rate parameters to currently
> existing ones, for example 'priority'.
Presumably you can't admission control at a granularity higher than
a queue, so grouping queues should cover all use cases.
> If this sounds acceptable I will work on the patch and submit it as
> soon, as it's ready.
I'd be curious to hear from nVidia and Corigine folks as well.
We can revive the switchdev call if talking over VC helps with
the alignment between vendors.
prev parent reply other threads:[~2022-07-06 19:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 11:45 [RFC] ice: Reconfigure tx scheduling for SR-IOV Michal Wilczynski
2022-07-05 22:15 ` Jakub Kicinski
2022-07-06 10:54 ` Wilczynski, Michal
2022-07-06 19:56 ` Jakub Kicinski [this message]
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=20220706125616.0a853dfc@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=dchumak@nvidia$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=konrad.knitter@intel$(echo .)com \
--cc=maximmi@nvidia$(echo .)com \
--cc=michal.wilczynski@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=simon.horman@corigine$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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