[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52cbca9f-503f-25b4-aabf-461d09f41e9f@gmail.com>
Date: Tue, 6 Aug 2024 14:28:16 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, dxu@...uu.xyz, przemyslaw.kitszel@...el.com,
donald.hunter@...il.com, gal.pressman@...ux.dev, tariqt@...dia.com,
willemdebruijn.kernel@...il.com, jdamato@...tly.com,
marcin.s.wojtas@...il.com, linux@...linux.org.uk
Subject: Re: [PATCH net-next v2 02/12] eth: mvpp2: implement new RSS context
API
On 05/08/2024 22:29, Jakub Kicinski wrote:
> On Mon, 5 Aug 2024 12:25:28 +0100 Edward Cree wrote:
>>> mvpp2 doesn't have a key for the hash, it defaults to
>>> an empty/previous indir table.
>>
>> Given that, should this be after patch #6? So as to make it
>> obviously correct not to populate ethtool_rxfh_context_key(ctx)
>> with the default context's key.
>
> It's a bit different. Patch 6 is about devices which have a key but
> the same key is used for all contexts. mvpp2 has no key at all
> even for context 0 (get_rxfh_key_size is not defined).
Oh, I see. Clarify that in the commit message, perhaps?
>>> @@ -5750,6 +5792,7 @@ static const struct net_device_ops mvpp2_netdev_ops = {
>>>
>>> static const struct ethtool_ops mvpp2_eth_tool_ops = {
>>> .cap_rss_ctx_supported = true,
>>> + .rxfh_max_context_id = MVPP22_N_RSS_TABLES,
>>
>> Max ID is inclusive, not exclusive, so I think this should be
>> MVPP22_N_RSS_TABLES - 1?
>
> I totally did check this before sending:
>
> * @rxfh_max_context_id: maximum (exclusive) supported RSS context ID. If this
> * is zero then the core may choose any (nonzero) ID, otherwise the core
> * will only use IDs strictly less than this value, as the @rss_context
> * argument to @create_rxfh_context and friends.
>
> But you're right, the code acts as if it was inclusive :S
Mea culpa, clearly when I was porting to XArray I must have
confused myself over this.
> Coincidentally, the default also appears exclusive:
>
> u32 limit = ops->rxfh_max_context_id ?: U32_MAX;
>
> U32_MAX can't be used, it has special meaning:
>
> #define ETH_RXFH_CONTEXT_ALLOC 0xffffffff
Given that both the default and drivers look more reasonable
with an exclusive than an inclusive limit (I assume most
drivers with a limit will have an N, like mvpp2 does, rather
than a MAX), I guess we should change the code to match the
doc rather than the other way around.
> These seem like net-worthy fixes, no?
Yep, agreed. I'll send a patch.
Powered by blists - more mailing lists