Why mlnx-ofed-kernel-utils package is being built in mlnx_add_kernel_support.sh scenario?

Infrastructure & Networking Software And Drivers Mellanox OFED
,
1

I will describe situation in terms of modern DOCA build infrastructure. Sorry for that, but I’m not allowed to create topic in the DOCA subcategory.

We’re using mainly distro kernels, but use pre-built module packages to avoid dkms and all build-deps to be installed and ran during node deploy process.
Also like the ability to have OFED packages installed for multiple kernels simultaneously. While built by doca-kernel-support kernel module packages have no path conflicts (and by package renaming simultaneous installation could be easily achieved), there should be only one mlnx-ofed-kernel-utils package installed.

What bothers me is that when using standard dkms installation modules are being built for multiple kernels but sharing the same mlnx-ofed-kernel-utils package, just as expected. It contrasts with doca-kernel-support way which builds separate mlnx-ofed-kernel-utils with kver version suffix.
Even diff added by build process vs shipped utils is unclear to me, e.g. for DOCA 2.9.2. LTS and standard ubuntu kernel:

diff -r mlnx-ofed-kernel-utils_24.10.OFED.24.10.2.1.8.1-1_amd64/control/control mlnx-ofed-kernel-utils_24.10.OFED.24.10.2.1.8.1-1.kver.5.4.0-208-generic_amd64/control/control
2,3c2,3
< Source: mlnx-ofed-kernel
< Version: 24.10.OFED.24.10.2.1.8.1-1
---
> Source: mlnx-ofed-kernel (24.10.OFED.24.10.2.1.8.1-1)
> Version: 24.10.OFED.24.10.2.1.8.1-1.kver.5.4.0-208-generic
7,8c7
< Depends: coreutils, pciutils, grep, procps, module-init-tools | kmod, lsof, mlnx-tools (>= 5.2.0)
< Conflicts: mlnx-en-utils
---
> Depends: coreutils, pciutils, grep, perl, procps, module-init-tools | kmod, lsof, mlnx-tools (>= 5.2.0)
diff -r mlnx-ofed-kernel-utils_24.10.OFED.24.10.2.1.8.1-1_amd64/data/etc/infiniband/openib.conf mlnx-ofed-kernel-utils_24.10.OFED.24.10.2.1.8.1-1.kver.5.4.0-208-generic_amd64/data/etc/infiniband/openib.conf
45a46,59
> # Load UMAD module
> UMAD_LOAD=yes
> # Load UVERBS module
> UVERBS_LOAD=yes
> # Load RDMA_CM module
> RDMA_CM_LOAD=yes
> # Load RDMA_UCM module
> RDMA_UCM_LOAD=yes
> # Load MLX5 modules
> MLX5_LOAD=yes
> # Load IPoIB
> IPOIB_LOAD=yes
> # Load SRP module
> SRP_LOAD=no

Diff in debian/control contents looks pretty insignificant. Diff in openib.conf follows from build configuration options --with-smth. But I assume that running doca-kernel-support with no env or cli parameters should lead to default configuration, so existence of this diff raises some questions.
And mainly, there are no kernel specifics added.

Do we really need mlnx-ofed-kernel-utils package being related to exact kernel version?

2

Hi,

For standard DKMS installs and general multiple kernel deployment use cases, there is no technical requirement for having separate mlnx-ofed-kernel-utils packages for each kernel version. The primary utilities in this package are user space tools and configuration files for managing Mellanox OFED kernel modules. As such, they are not generally tied to a specific kernel build, and in most upstream or distribution-integrated workflows (including DKMS), a single mlnx-ofed-kernel-utils package is used for all supported kernels—this is standard and expected behavior.

If there are any additional questions, please send an E-Mail to enterprisesupport@nvidia.com, and it will be handled based on entitlement.

Thanks,
Jonathan.

3

Thank you for the clarification!

For standard DKMS installs and general multiple kernel deployment use cases, there is no technical requirement for having separate mlnx-ofed-kernel-utils packages for each kernel version

Does that mean that mlnx-ofed-kernel-utils deb package produced by doca-kernel-support can be safely thrown out after build and installing mlnx-ofed-kernel-utils from OFED binary distribution along with doca-kernel-support-built kernel drivers should be safe for general use cases?