From: Edward Cree <ecree.xilinx@gmail.com>
To: "Wilczynski, Michal" <michal.wilczynski@intel.com>,
netdev@vger.kernel.org
Cc: alexandr.lobakin@intel.com, dchumak@nvidia.com,
maximmi@nvidia.com, jiri@resnulli.us, simon.horman@corigine.com,
jacob.e.keller@intel.com, jesse.brandeburg@intel.com,
przemyslaw.kitszel@intel.com
Subject: Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new parameters
Date: Thu, 15 Sep 2022 22:01:55 +0100 [thread overview]
Message-ID: <df4cd224-fc1b-dcd0-b7d4-22b80e6c1821@gmail.com> (raw)
In-Reply-To: <401d70a9-5f6d-ed46-117b-de0b82a5f52c@intel.com>
On 15/09/2022 19:41, Wilczynski, Michal wrote:
> Hi,
> Previously we discussed adding queues to devlink-rate in this thread:
> https://lore.kernel.org/netdev/20220704114513.2958937-1-michal.wilczynski@intel.com/T/#u
> In our use case we are trying to find a way to expose hardware Tx scheduler tree that is defined
> per port to user. Obviously if the tree is defined per physical port, all the scheduling nodes will reside
> on the same tree.
>
> Our customer is trying to send different types of traffic that require different QoS levels on the same
> VM, but on a different queues. This requires completely different rate setups for that queue - in the
> implementation that you're mentioning we wouldn't be able to arbitrarily reassign the queue to any node.
I'm not sure I 100% understand what you're describing, but I get the
impression it's maybe a layering violation — the hypervisor should only
be responsible for shaping the VM's overall traffic, it should be up to
the VM to decide how to distribute that bandwidth between traffic types.
But if it's what your customer needs then presumably there's some reason
for it that I'm not seeing. I'm not a QoS expert by any means — I just
get antsy that every time I look at devlink it's gotten bigger and keeps
escaping further out of the "device-wide configuration" concept it was
originally sold as :(
> Those queues would still need to share a single parent - their netdev. This wouldn't allow us to fully take
> advantage of the HQoS and would introduce arbitrary limitations.
Oh, so you need a hierarchy within which the VF's queues don't form a
clade (subtree)? That sounds like something worth calling out in the
commit message as the reason why you've designed it this way.
> Regarding the documentation, sure. I just wanted to get all the feedback from the mailing list and arrive at the final
> solution before writing the docs.
Fair. But you might get better feedback on the code if people have the
docs to better understand the intent; just a suggestion.
-ed
next prev parent reply other threads:[~2022-09-15 21:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-15 13:42 [RFC PATCH net-next v4 0/6] Implement devlink-rate API and extend it Michal Wilczynski
2022-09-15 13:42 ` [RFC PATCH net-next v4 1/6] ice: Add function for move/reconfigure TxQ AQ command Michal Wilczynski
2022-09-15 13:42 ` [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new parameters Michal Wilczynski
2022-09-15 15:31 ` Edward Cree
2022-09-15 18:41 ` Wilczynski, Michal
2022-09-15 21:01 ` Edward Cree [this message]
2022-09-19 13:12 ` Wilczynski, Michal
2022-09-20 11:09 ` Edward Cree
2022-09-26 11:58 ` Jiri Pirko
2022-09-28 11:53 ` Wilczynski, Michal
2022-09-29 7:08 ` Jiri Pirko
2022-09-21 23:33 ` Jakub Kicinski
2022-09-22 11:44 ` Wilczynski, Michal
2022-09-22 12:50 ` Jakub Kicinski
2022-09-22 13:45 ` Wilczynski, Michal
2022-09-22 20:29 ` Jakub Kicinski
2022-09-23 12:11 ` Wilczynski, Michal
2022-09-23 13:16 ` Jakub Kicinski
2022-09-23 15:46 ` Wilczynski, Michal
2022-09-27 0:16 ` Jakub Kicinski
2022-09-28 12:02 ` Wilczynski, Michal
2022-09-28 17:39 ` Jakub Kicinski
2022-09-26 11:51 ` Jiri Pirko
2022-09-28 11:47 ` Wilczynski, Michal
2022-09-29 7:12 ` Jiri Pirko
2022-10-11 13:28 ` Wilczynski, Michal
2022-10-11 14:17 ` Jiri Pirko
2022-09-15 13:42 ` [RFC PATCH net-next v4 3/6] ice: Introduce new parameters in ice_sched_node Michal Wilczynski
2022-09-15 13:42 ` [RFC PATCH net-next v4 4/6] ice: Implement devlink-rate API Michal Wilczynski
2022-09-22 13:08 ` Przemek Kitszel
2022-09-15 13:42 ` [RFC PATCH net-next v4 5/6] ice: Export Tx scheduler configuration to devlink-rate Michal Wilczynski
2022-09-15 13:42 ` [RFC PATCH net-next v4 6/6] ice: Prevent ADQ, DCB and RDMA coexistence with Custom Tx scheduler Michal Wilczynski
2022-09-15 13:57 ` [RFC PATCH net-next v4 0/6] Implement devlink-rate API and extend it Wilczynski, Michal
2022-09-19 7:22 [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new parameters kernel test robot
2022-09-19 9:22 ` Dan Carpenter
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=df4cd224-fc1b-dcd0-b7d4-22b80e6c1821@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=alexandr.lobakin@intel.com \
--cc=dchumak@nvidia.com \
--cc=jacob.e.keller@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=maximmi@nvidia.com \
--cc=michal.wilczynski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=simon.horman@corigine.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.