Page MenuHomeFreeBSD

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

Authored by pkubaj on Feb 25 2023, 9:20 PM.
Tags
None
Referenced Files
F108593211: D38786.id117981.diff
Sun, Jan 26, 6:07 PM
F108592326: D38786.id117936.diff
Sun, Jan 26, 5:58 PM
Unknown Object (File)
Sat, Jan 18, 9:27 PM
Unknown Object (File)
Sat, Jan 18, 2:32 PM
Unknown Object (File)
Fri, Jan 10, 6:43 PM
Unknown Object (File)
Fri, Jan 10, 6:25 PM
Unknown Object (File)
Fri, Jan 10, 3:59 PM
Unknown Object (File)
Dec 5 2024, 4:32 AM

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)