From: Jakub Kicinski <kuba@kernel.org>
To: Edward Cree <ecree.xilinx@gmail.com>
Cc: Ahmed Zaki <ahmed.zaki@intel.com>, netdev@vger.kernel.org
Subject: Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to get/set_rxfh ethtool ops
Date: Tue, 4 Jun 2024 10:33:59 -0700 [thread overview]
Message-ID: <20240604103359.7b7be651@kernel.org> (raw)
In-Reply-To: <e0d451be-8c22-332b-bd6b-09edc4d25c97@gmail.com>
On Tue, 4 Jun 2024 15:58:02 +0100 Edward Cree wrote:
> > Can we avoid the confusion by careful wording of the related kdoc?
> > "context" is the current state, while "params" describe the intended
> > configuration. If we move the "no_change" bits over to "params",
> > I hope it wouldn't be all that confusing.
>
> I think "no_change" should stay in "context", but be renamed.
> ("params" has them implicitly via setting indir_size to
> ETH_RXFH_INDIR_NO_CHANGE or key_size to zero.)
> The bits in "context" mean that indir or key has *never* been
> configured for this context, and therefore the driver should
> make up a default. In that case, if the context has to be
> recreated (e.g. after a device reset, or maybe an ethtool -L
> changing the number of RXQs), the driver could generate a
> different table. (Also, unless the driver decides to write
> the generated default table back into "context" by hand, the
> core won't be able to show it to userspace in netlink dumps
> when those get added.)
Ah, great point!
> So I guess context.indir_no_change should really be called
> something like .indir_unspecified?
/me looks at the code
We already have IFF_RXFH_CONFIGURED, and corresponding
netif_is_rxfh_configured(). Should we stick to "${field}_configured"?
> Or should the core just insist on handling default generation
> itself (but then it can't be sure of producing defaults that
> a device with limited resources can honour), or have yet
> another op to populate the defaults into params when the
> user didn't specify them?
Thinking this over during breakfast I concluded we should leave out
feeding the defaults into drivers for now.
The only useful fields we could pre-populate are indir table and
key (useful because it'd save drivers calling some ethtool_default*
helpers). But both of those are fairly complex. Key may not be
populated for dynamically created contexts at all. Indir table
may have different sizes and has to be re-calculated when queue
count changes.
next prev parent reply other threads:[~2024-06-04 17:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 20:56 [PATCH net-next v6 0/7] Support symmetric-xor RSS hash Ahmed Zaki
2023-11-20 20:56 ` [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to get/set_rxfh ethtool ops Ahmed Zaki
2023-11-21 23:29 ` Jakub Kicinski
2023-11-27 14:14 ` Ahmed Zaki
2023-11-27 16:55 ` Jakub Kicinski
2023-11-27 17:10 ` Edward Cree
2023-11-27 18:04 ` Jakub Kicinski
2024-06-03 18:54 ` Edward Cree
2024-06-03 23:17 ` Jakub Kicinski
2024-06-04 14:58 ` Edward Cree
2024-06-04 17:33 ` Jakub Kicinski [this message]
2023-11-28 20:19 ` Keller, Jacob E
2024-06-05 17:42 ` Gal Pressman
2024-06-05 17:56 ` Ahmed Zaki
2024-06-05 18:27 ` Keller, Jacob E
2023-11-20 20:56 ` [PATCH net-next v6 2/7] net: ethtool: add support for symmetric-xor RSS hash Ahmed Zaki
2023-11-21 23:33 ` Jakub Kicinski
2023-11-23 13:33 ` Gal Pressman
2023-11-23 16:27 ` Jakub Kicinski
2023-11-27 14:21 ` Ahmed Zaki
2023-11-27 16:57 ` Jakub Kicinski
2023-11-20 20:56 ` [PATCH net-next v6 3/7] ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values Ahmed Zaki
2023-11-20 20:56 ` [PATCH net-next v6 4/7] ice: refactor RSS configuration Ahmed Zaki
2023-11-20 20:56 ` [PATCH net-next v6 5/7] ice: refactor the FD and RSS flow ID generation Ahmed Zaki
2023-11-20 20:56 ` [PATCH net-next v6 6/7] ice: enable symmetric-xor RSS for Toeplitz hash function Ahmed Zaki
2023-11-20 20:56 ` [PATCH net-next v6 7/7] iavf: " Ahmed Zaki
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=20240604103359.7b7be651@kernel.org \
--to=kuba@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=ecree.xilinx@gmail.com \
--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).