From: Jakub Kicinski <kuba@kernel•org>
To: "Wilczynski, Michal" <michal.wilczynski@intel•com>
Cc: Edward Cree <ecree.xilinx@gmail•com>, <netdev@vger•kernel.org>,
<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: Wed, 28 Sep 2022 10:39:51 -0700 [thread overview]
Message-ID: <20220928103951.45fc326d@kernel.org> (raw)
In-Reply-To: <0ae7b664-e84a-218a-8276-a94a78f6c510@intel.com>
On Wed, 28 Sep 2022 14:02:57 +0200 Wilczynski, Michal wrote:
> > AFAIU you only want to cater to simple cases where the VF and PF
> > are in the same control domain, which is not normal, outside of
> > running DPDK apps. Sooner or later someone will ask for queuing
> > control from the VFs and you're have to redesign the whole thing.
>
> Hmm, so I guess the queue part of this patch is not well liked.
> I wonder if I should re-send this patch with just the implementation
> of devlink-rate, and minor changes in devlink, like exposing functions,
> so the driver can export initial configurations. This still brings some
> value,
> cause the user would still be able to modify at least the upper part of the
> tree.
Sounds good to me. I don't think we ever had a general discussion
about what should the driver do in terms of exposing the initial
configuration. I can't think of a reason why we wouldn't do that
so please repost and let's see what others think!
> We can still discuss how the final solution should look like, but i'm
> out of ideas when it comes for a inside VF interface, (like we
> discussed tc-htb in current form doesn't really work for us).
next prev parent reply other threads:[~2022-09-28 17:40 UTC|newest]
Thread overview: 33+ 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
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 [this message]
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
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=20220928103951.45fc326d@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=alexandr.lobakin@intel$(echo .)com \
--cc=dchumak@nvidia$(echo .)com \
--cc=ecree.xilinx@gmail$(echo .)com \
--cc=jacob.e.keller@intel$(echo .)com \
--cc=jesse.brandeburg@intel$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=maximmi@nvidia$(echo .)com \
--cc=michal.wilczynski@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=przemyslaw.kitszel@intel$(echo .)com \
--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