linux-doc.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, intel-wired-lan@lists.osuosl.org,
	corbet@lwn.net, jesse.brandeburg@intel.com,
	anthony.l.nguyen@intel.com, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, vladimir.oltean@nxp.com,
	andrew@lunn.ch, horms@kernel.org, mkubecek@suse.cz,
	willemdebruijn.kernel@gmail.com, gal@nvidia.com,
	alexander.duyck@gmail.com, linux-doc@vger.kernel.org,
	Igor Bagnucki <igor.bagnucki@intel.com>,
	Jacob Keller <jacob.e.keller@intel.com>
Subject: Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to get/set_rxfh ethtool ops
Date: Mon, 27 Nov 2023 10:04:58 -0800	[thread overview]
Message-ID: <20231127100458.48e0ff6e@kernel.org> (raw)
In-Reply-To: <81014d9d-4642-6a6b-2a44-02229cd734f9@gmail.com>

On Mon, 27 Nov 2023 17:10:37 +0000 Edward Cree wrote:
> Yep, I had noticed.  Was wondering how the removal of the old
>  [sg]et_rxfh_context functions would interact with my new API,
>  which has three ops (create/modify/delete) and thus can't
>  really be wedged into the [sg]et_rxfh() like that.

Set side looks fairly straightforward. Get is indeed more tricky.

> Tbh I'd rather move in the direction of using the new API (and
>  associated state-in-core) for everything, even context 0, so
>  that the behaviour is consistent between default and custom
>  contexts for NICs that support the latter.  Not 100% sure how
>  exactly that would work in practice yet though; drivers are
>  currently responsible for populating ctx 0 (indir, key, etc)
>  at probe time so how do you read that state into the core?

We can try to slowly move drivers over from the "pull model"
to a "push model" where they inform the core about the change
they have made. The main thing to worry about will probably
be the indirection table, as queues get reconfigured.

Maybe we can tie the switch over to the multi-context support?

Or wait with the conversion until the new API gets some use
for the non-0 context..

> And I promise v5 of the rework is coming eventually, bosses
>  just keep prioritising everything but this :(

Right, which is why I'm not asking Ahmed to worry about/wait for 
your work :)

  reply	other threads:[~2023-11-27 18:04 UTC|newest]

Thread overview: 22+ 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 [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=20231127100458.48e0ff6e@kernel.org \
    --to=kuba@kernel.org \
    --cc=ahmed.zaki@intel.com \
    --cc=alexander.duyck@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=horms@kernel.org \
    --cc=igor.bagnucki@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=willemdebruijn.kernel@gmail.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 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).