Survey: anyone running a fully functional in-tree DFL stack (6.18.x/7.0.x) with Intel N3000 PAC?

Hi all,

I would like to ask the wider linux-fpga community a practical question about
the state of the Intel FPGA PAC N3000 (SmartNIC card) on recent mainline
kernels.

Are there organisations, teams or community groups out there that currently
run - or have previously validated - a *complete and functional* N3000 stack
based solely on the in-tree DFL drivers on 6.18.x or 7.0.x, without carrying
the out-of-tree linux-dfl tree?

By "complete and functional" I mean roughly the following, and I would be
glad to hear about partial answers too:

  - DFL enumeration and FME/AFU access via dfl-pci / dfl-fme / dfl-afu
  - MAX10 BMC (intel-m10-bmc) with sensors, security/root-entry-hash sysfs
  - Secure update / RSU (intel-m10-bmc-sec-update) working end-to-end,
    including the card coming back cleanly after an RSU reset
  - PKVL retimer firmware handling
  - The i40e/i40evf side of the SmartNIC: PF bring-up plus SR-IOV VF
    allocation surviving a card re-enumeration
  - OPAE userspace (opae-sdk) working against the in-tree ABI

The reason I am asking: we are moving a product from 6.12 to 6.18, and while
6.12 behaved well, on 6.18.15 we see i40e sriov_configure() fail with -ENOMEM
("not enough MMIO resources for SR-IOV") after an RSU reset re-enumerates the
card. That looks related to the PCI resource-fitting rework in 6.15-6.18, and
we have a candidate set of setup-bus.c fixes queued for testing. Separately,
the in-tree m10bmc secure-update driver still lacks the control/image_load ABI
that linux-dfl carries, which I have proposed for mainline here:

  https://lore.kernel.org/lkml/[email protected]/

Before we invest further, it would be very useful to know whether anyone else
is exercising this hardware on current mainline. Concretely:

  1. Is anyone running N3000 on 6.18.x or 7.0.x today, in production, CI or
     lab? If so, purely in-tree, or with linux-dfl / vendor patches on top?
  2. Has anyone seen the same post-RSU SR-IOV resource-allocation failure on
     6.15+, and is there a known fix or workaround beyond pci=realloc (which
     is a no-op on the rescan path)?
  3. Is there any regularly exercised test coverage for DFL-based cards on
     recent kernels that we could contribute to, rather than duplicating
     internally?
  4. Is the N3000 still considered actively supported in-tree, or is it now
     effectively in maintenance-only status with N6000/PMCI being the focus?

Any data point would be genuinely helpful - including "we gave up and stayed
on linux-dfl" or "we are still on an older kernel for exactly this reason".
If there is enough interest I will summarise the replies back to the list,
and I will of course report what we find on the PCI resource side.

Thanks in advance,
Ionut

--
Ionut Nechita
Wind River
[email protected]