On 2/10/2025 11:55 PM, Leon Romanovsky wrote:
On Mon, Feb 10, 2025 at 05:04:23PM -0800, Jakub Kicinski wrote:
On Fri, 7 Feb 2025 21:16:47 -0400 Jason Gunthorpe wrote:
On Fri, Feb 07, 2025 at 01:51:11PM -0800, Jakub Kicinski wrote:
But if you agree the netdev doesn't need it seems like a fairly
straightforward way to unblock your progress.
I'm trying to understand what you are suggesting here.
We have many scenarios where mlx5_core spawns all kinds of different
devices, including recovery cases where there is no networking at all
and only fwctl. So we can't just discard the aux dev or mlx5_core
triggered setup without breaking scenarios.
However, you seem to be suggesting that netdev-only configurations (ie
netdev loaded but no rdma loaded) should disable fwctl. Is that the
case? All else would remain the same. It is very ugly but I could see
a technical path to do it, and would consider it if that brings peace.
Yes, when RDMA driver is not loaded there should be no access to fwctl.
There are users mentioned in cover letter, which need FWCTL without RDMA.
https://lore.kernel.org/all/0-v4-0cf4ec3b8143+4995-fwctl_jgg@xxxxxxxxxx/
I want to suggest something different. What about to move all XXX_core
logic (mlx5_core, bnxt_core, e.t.c.) from netdev to some other dedicated
place?
There is no technical need to have PCI/FW logic inside networking stack.
Thanks
Our pds_core device fits this description as well: it is not an ethernet
PCI device, but helps manage the FW/HW for Eth and other things that are
separate PCI functions. We ended up in the netdev arena because we
first went in as a support for vDPA VFs.
Should these 'core' devices live in linux-pci land? Is it possible that
some 'core' things might be platform devices rather than PCI?
sln
