lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231127100458.48e0ff6e@kernel.org>
Date: Mon, 27 Nov 2023 10:04:58 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Ahmed Zaki <ahmed.zaki@...el.com>, netdev@...r.kernel.org,
 intel-wired-lan@...ts.osuosl.org, corbet@....net,
 jesse.brandeburg@...el.com, anthony.l.nguyen@...el.com,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 vladimir.oltean@....com, andrew@...n.ch, horms@...nel.org,
 mkubecek@...e.cz, willemdebruijn.kernel@...il.com, gal@...dia.com,
 alexander.duyck@...il.com, linux-doc@...r.kernel.org, Igor Bagnucki
 <igor.bagnucki@...el.com>, Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next v6 1/7] net: ethtool: pass ethtool_rxfh to
 get/set_rxfh ethtool ops

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 :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ