Nebula Matrix NBL heads toward Linux 7.4
Phoronix reports that Nebula Matrix’s initial driver was merged into net-next during the preceding week and is expected to be submitted for the Linux 7.4 merge window. That is the release target to watch, rather than a reason to change a production server’s kernel immediately. The available corroborating material establishes the driver-development work; independent confirmation of the reported merge timing is not available here.
There is also a version-number error worth clearing up. Phoronix’s opening sentence calls the target “Linux 6.4,” while its headline, subsequent description and closing merge-window reference all say Linux 7.4. Linux 7.4 is therefore the reported intended target; neither the inconsistent wording nor the September patch submissions should be treated as a release guarantee.
The hardware is aimed at a specific audience. Phoronix describes the S1000 series as a PCIe Gen4 x16 adapter family with configurations offering up to two 100G interfaces, intended for cloud computing, high-performance computing and related data-center workloads. It also reports that Nebula Matrix already supplies Windows and Linux drivers. This development concerns upstream Linux support, with no corresponding Windows driver change announced in that reporting.
NBL’s patch sequence needs to be read as a sequence
Nebula Matrix’s September 14 v28 submission provides concrete evidence of the upstream work. Its first patch adds the build framework, driver documentation, maintainer entries and PCI device identifiers for the m18110/m18000 family. The documentation identifies these devices as SNIC S1000 products and describes PCI resource management, firmware communication, and device initialization and teardown.
One detail can easily produce a misleading conclusion: the first patch’s nbl_probe() function returns -ENODEV. Read alone, that skeleton does not initialize a usable adapter. But the patch explicitly says implementation follows in subsequent patches, so the first patch cannot establish the capability of the completed series.
The second patch’s description makes the progression explicit. It binds the PCI device but does not yet create or register a Linux network interface, and says network-device support will be added later in the series. At that intermediate stage, Ethernet transmit and receive queues and their data-plane interrupts remain unconfigured and disabled.
A later patch describes chip-wide initialization for the Leonis hardware, including packet-processing engines, scheduling, buffers, queue management, traffic shaping and flow control. That supports a more substantial picture than a driver consisting only of device identifiers, without demonstrating production readiness or measured networking performance.
For administrators, the useful distinction is between recognizing hardware, initializing its control facilities and exposing working Ethernet connectivity. Evidence about an intermediate patch should not be promoted into either a promise that the final driver is fully functional or a verdict that it cannot work.
SNIC S1000 documentation narrows the compatibility check
The September framework defines CONFIG_NBL, with nbl as the module name when built as a module. Its configuration requires PCI and a 64-bit build, with an exception for compile testing, and excludes big-endian CPUs. The compile-testing exception should not be read as a promise of supported 32-bit deployment.
The device table supplies another useful inventory detail: Nebula Matrix’s vendor ID is 0x1F0F, and the listed m18110/m18000 variants span device IDs 0x3403 through 0x3412. Those identifiers help establish whether an adapter belongs to the family addressed by this work; they do not establish that every feature needed by a deployment is implemented.
Documentation also changed between revisions. The August v24 framework described 100GbE, 25GbE and 10GbE operation, per-queue interrupts, interrupt moderation, checksum offload and Receive-Side Scaling. The September v28 framework instead describes core infrastructure and firmware communication.
That textual change is important when assessing support. The older feature list is insufficient evidence that the eventual Linux 7.4 driver will deliver all those capabilities. Equally, the narrower description alone does not prove that features were removed. A deployment decision needs the final driver’s feature coverage, rather than a hardware specification or an earlier patch’s overview.
SNIC S1000 administrators should plan validation, not an immediate migration
Keep production driver replacement off the schedule until the released kernel and required adapter capabilities are established. The current evidence is useful for compatibility planning:
- Match installed hardware against the m18110/m18000 family and its PCI identifiers, rather than relying solely on S1000 branding.
- Treat Linux 7.4 as Phoronix’s reported target, not as an already available supported configuration.
- For a prospective kernel build, identify whether
CONFIG_NBLis enabled and whether support is built in or supplied as thenblmodule. - Establish the final driver’s required feature coverage before replacing a working deployment; neither an early skeleton nor an older feature list answers that question.
- Keep Windows driver decisions separate, because this milestone concerns Linux upstream development.
NBL’s progress gives SNIC S1000 operators a concrete upstream-support development to track. The next useful decision point is the driver’s inclusion and documented capabilities in a released kernel: that is when the prospect of easier maintenance can become a specific migration plan.