[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <98a48c7b-539e-41b3-ab3c-e2398401c7f7@gmail.com>
Date: Mon, 16 Jun 2025 16:32:25 +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, andrew+netdev@...n.ch, horms@...nel.org,
bharat@...lsio.com, benve@...co.com, satishkh@...co.com,
claudiu.manoil@....com, vladimir.oltean@....com, wei.fang@....com,
xiaoning.wang@....com, anthony.l.nguyen@...el.com,
przemyslaw.kitszel@...el.com, bryan.whitehead@...rochip.com,
rosenp@...il.com, imx@...ts.linux.dev
Subject: Re: [PATCH net-next 6/6] eth: sfc: falcon: migrate to new RXFH
callbacks
On 13/06/2025 15:50, Jakub Kicinski wrote:
> On Fri, 13 Jun 2025 14:44:40 +0100 Edward Cree wrote:
>> So granted that you're only moving code, but looking at this it doesn't
>> actually make sense, since every path that sets info->data to nonzero
>> also sets min_revision, so why not just do the ef4_nic_rev() check at
>> the start? Answer, from git log spelunking, is that when this code was
>> shared with Siena, EFX_REV_SIENA_A0 supported IPv6 here.
>
> Ack, I was tempted to clean this up, but it felt slightly outside of
> the objective. Looks like I need to respin for enetc - I can change
> it in v2 if you'd like?
I'd say just keep your patch as is, then I'll send a follow-up that does
the refactor and also adds a comment about why the hashing config is what
it is.
Powered by blists - more mailing lists