Page MenuHomeFreeBSD

powerpc64*: port mlx5, OFED, KTLS and krping
ClosedPublic

Authored by pkubaj on Feb 25 2023, 9:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Oct 17, 2:40 AM
Unknown Object (File)
Sep 26 2024, 8:23 PM
Unknown Object (File)
Sep 25 2024, 10:49 PM
Unknown Object (File)
Sep 20 2024, 9:01 AM
Unknown Object (File)
Sep 18 2024, 2:41 AM
Unknown Object (File)
Sep 11 2024, 2:27 PM
Unknown Object (File)
Sep 8 2024, 11:36 PM
Unknown Object (File)
Sep 8 2024, 7:06 PM

Details

Summary

This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.

krping requires a small change since it uses assembly for amd64 / i386.

NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian. Thus, on powerpc64 I verified that RDMA works with krping.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 50019
Build 46911: arc lint + arc unit

Event Timeline

This revision was not accepted when it landed; it landed in state Needs Review.Feb 25 2023, 11:57 PM
This revision was automatically updated to reflect the committed changes.

Have a look at my comment. Looks good!

sys/contrib/rdma/krping/krping.c
77

Is the builting supported for amd64 and i386 aswell?

sys/contrib/rdma/krping/krping.c
77

Apparently it is, but I have not tested on amd64 and i386. According to https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions, it works everywhere.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 26 2023, 10:39 PM
This revision was automatically updated to reflect the committed changes.

FWIW, I would probably have split this up into a few commits to make it easier for someone in the future to bisect if this triggers some kind of breakage (e.g. KERN_TLS separate from base mlx5 separate from OFED)