On 27/11/2023 16:55, Jakub Kicinski wrote: > BTW, Ed, this series will conflict with your RSS context rework. > Not sure if it is on your radar.
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. 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? And I promise v5 of the rework is coming eventually, bosses just keep prioritising everything but this :( _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
