From: Edward Cree <ecree.xilinx@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>, edward.cree@amd.com
Cc: linux-net-drivers@amd.com, davem@davemloft.com,
edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org,
habetsm.xilinx@gmail.com, sudheer.mogilappagari@intel.com,
jdamato@fastly.com, mw@semihalf.com, linux@armlinux.org.uk,
sgoutham@marvell.com, gakula@marvell.com, sbhatta@marvell.com,
hkelam@marvell.com, saeedm@nvidia.com, leon@kernel.org,
jacob.e.keller@intel.com, andrew@lunn.ch, ahmed.zaki@intel.com
Subject: Re: [PATCH v5 net-next 4/7] net: ethtool: let the core choose RSS context IDs
Date: Thu, 20 Jun 2024 05:42:49 +0100 [thread overview]
Message-ID: <b00f5093-d1d2-45a1-4af2-4c98f6d3fb32@gmail.com> (raw)
In-Reply-To: <20240619102435.52b7be88@kernel.org>
On 19/06/2024 18:24, Jakub Kicinski wrote:
> On Tue, 18 Jun 2024 23:44:24 +0100 edward.cree@amd.com wrote:
>> + * @create_rxfh_context: Create a new RSS context with the specified RX flow
>> + * hash indirection table, hash key, and hash function.
>> + * Parameters which are set to %NULL or zero will be populated to
>> + * appropriate defaults by the driver.
>
> The defaults will most likely "inherit" whatever is set in context 0.
> So the driver _may_ init the values according to its preferences
> but they will not be used by the core (specifically not reported to
> user space via ethtool netlink)
>
> Does that match your thinking?
Yes, that was what I had in mind.
> Indirection table needs to get reported.
Okay, I'll alter the documentation to say so, that notwithstanding
this bit...
>> + * The &struct ethtool_rxfh_context for this context is passed in @ctx;
>> + * note that the indir table, hkey and hfunc are not yet populated as
>> + * of this call. The driver does not need to update these; the core
>> + * will do so if this op succeeds.
... at least indir MUST, and the others MAY, be filled in by the
driver if they weren't specified in params.
(sfc does this already, because it uses the ctx as a place to store
the new table and/or key if it has to generate them.)
>> + int (*remove_rxfh_context)(struct net_device *,
>> + struct ethtool_rxfh_context *ctx,
>> + u32 rss_context);
>
> Can we make remove void? It's sort of a cleanup, cleanups which can
> fail make life hard.
At least on sfc it's possible for it to fail. Apart from anything
else, I don't think there's anything in the core to catch the case
of trying to remove a context while there are still ntuple filters
targeting it; I believe that gets all the way down to the firmware,
which responds EBUSY or something. If that happens, we don't want
to pretend it worked and delete the context from the xarray.
-ed
next prev parent reply other threads:[~2024-06-20 4:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 22:44 [PATCH v5 net-next 0/7] ethtool: track custom RSS contexts in the core edward.cree
2024-06-18 22:44 ` [PATCH v5 net-next 1/7] net: move ethtool-related netdev state into its own struct edward.cree
2024-06-18 23:05 ` David Wei
2024-06-18 23:43 ` Jakub Kicinski
2024-06-18 23:45 ` David Wei
2024-06-19 0:21 ` Jakub Kicinski
2024-06-18 22:44 ` [PATCH v5 net-next 2/7] net: ethtool: attach an XArray of custom RSS contexts to a netdevice edward.cree
2024-06-18 23:49 ` Jakub Kicinski
2024-06-19 14:30 ` Jakub Kicinski
2024-06-18 22:44 ` [PATCH v5 net-next 3/7] net: ethtool: record custom RSS contexts in the XArray edward.cree
2024-06-19 0:46 ` David Wei
2024-06-19 11:59 ` Edward Cree
2024-06-18 22:44 ` [PATCH v5 net-next 4/7] net: ethtool: let the core choose RSS context IDs edward.cree
2024-06-19 17:24 ` Jakub Kicinski
2024-06-19 20:08 ` Jakub Kicinski
2024-06-20 4:42 ` Edward Cree [this message]
2024-06-18 22:44 ` [PATCH v5 net-next 5/7] net: ethtool: add an extack parameter to new rxfh_context APIs edward.cree
2024-06-18 22:44 ` [PATCH v5 net-next 6/7] net: ethtool: add a mutex protecting RSS contexts edward.cree
2024-06-18 22:44 ` [PATCH v5 net-next 7/7] sfc: use new rxfh_context API edward.cree
2024-06-19 0:19 ` [PATCH v5 net-next 0/7] ethtool: track custom RSS contexts in the core Jakub Kicinski
2024-06-19 12:00 ` Edward Cree
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=b00f5093-d1d2-45a1-4af2-4c98f6d3fb32@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=ahmed.zaki@intel.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.com \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=gakula@marvell.com \
--cc=habetsm.xilinx@gmail.com \
--cc=hkelam@marvell.com \
--cc=jacob.e.keller@intel.com \
--cc=jdamato@fastly.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=linux@armlinux.org.uk \
--cc=mw@semihalf.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
--cc=sudheer.mogilappagari@intel.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).