Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [net 0/2] rxfh with custom RSS fixes
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Joe Damato <jdamato@fastly.com>, netdev@vger.kernel.org,
        saeedm@nvidia.com, tariqt@nvidia.com, ecree@solarflare.com,
        andrew@lunn.ch, davem@davemloft.net, leon@kernel.org,
        pabeni@redhat.com, bhutchings@solarflare.com, arnd@arndb.de,
        linux-kernel@vger.kernel.org
References: <20230723150658.241597-1-jdamato@fastly.com>
 <b52f55ef-f166-cd1a-85b5-5fe32fe5f525@gmail.com>
 <20230724150815.494ae294@kernel.org>
From:   Edward Cree <ecree.xilinx@gmail.com>
Message-ID: <f565a8d6-e3b8-96d1-a7ac-212c64c60b1c@gmail.com>
Date:   Tue, 25 Jul 2023 09:40:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <20230724150815.494ae294@kernel.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 24/07/2023 23:08, Jakub Kicinski wrote:
> What's the status on your work? Are you planning to split the RSS
> config from ethtool or am I reading too much into what you said?

I was just thinking that when netlink dumps get added it would make
 sense to also extend the netlink version of SRSSH (which is what
 calls the rxfh_context ethtool_ops, via the misleadingly named
 ethtool_set_rxfh()) to include the hash fields setting that's
 currently done through ETHTOOL_SRXFH.  In which case I should add
 that data to struct ethtool_rxfh_context, and include it in the
 get/create/modify_rss_context ethtool_ops API.
Since it only occurred to me to consider that setting when I saw
 Joe's patches, I haven't really figured out yet how to go about
 the implementation of that.

More generally the status of my RSS work is that I've been umming
 and ahhing about that mutex you didn't like (I still think it's
 the Right Thing) so I've not made much progress with it.
And I should place on record that probably once I've gotten the
 kernel-driver API done I'll leave the netlink/uAPI stuff for
 someone else to do as I really don't have the relevant expertise.

> It'd be great to push the uAPI extensions back and make them
> netlink-only, but we can't make Joe wait if it takes a long time
> to finish up the basic conversion :(

Yeah as I said upthread I don't think we should make Joe wait, if
 he's got a use case that actually needs it (have you, Joe?  Or
 is it only GRXFH you need and the investigation just led you to
 notice SRXFH was broken?)

-ed