netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).