librdmacm/libibverbs: Add bnxtre RDMA provider to OFED build infrastructure
ClosedPublic
Actions

Authored by sreekanth.reddy_broadcom.com on Fri, Dec 26, 10:47 AM.

Details

Reviewers

sumit.saxena_broadcom.com
markj
jrtc27

Commits

rG821c6c43a33d: librdmacm/libibverbs: Add bnxtre RDMA provider to OFED build infrastructure

Summary

Extend the FreeBSD OFED build framework to include the Broadcom bnxtre RDMA
provider library.

This change:

Registers libbnxtre in src.libnames.mk so it is built and installed as part of the OFED libraries.
Adds bnxtre to the OFED pcap dependency set when MK_OFED is enabled.
Declares proper dependency mappings for bnxtre (ibverbs, pthread).
Introduces LIBBNXTREDIR for consistent object directory handling.
Updates libibverbs and librdmacm build rules to link against libbnxtre, enabling Broadcom RoCE device support at runtime.
libbnxtre library uses below constructor to register with the libibverbs, static attribute((constructor)) void bnxt_re_register_driver(void)

These updates ensure that applications using libibverbs and librdmacm can discover
and use Broadcom bnxt RDMA devices on FreeBSD.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

sreekanth.reddy_broadcom.com created this revision.Fri, Dec 26, 10:47 AM

Herald added subscribers: emaste, bdrewery. · View Herald TranscriptFri, Dec 26, 10:47 AM

sreekanth.reddy_broadcom.com requested review of this revision.Fri, Dec 26, 10:47 AM

I don't understand. This patch is already applied to the tree, commit 35dd53a9e1326.

In D54368#1243161, @markj wrote:

I don't understand. This patch is already applied to the tree, commit 35dd53a9e1326.

Oh, it was reverted. It's the same diff as before as far as I can see, just the commit log message changed. It looks like Jessica's main question is, why exactly is it necessary to link libbnxtre:

> Secondly, this states some things, but I don’t see why this change
> follows from it. *Why* does it matter that ibv_devices and rping do not
> link against libbnxtre? If it builds, that means none of libbnxtre’s
> symbols were needed. Is there some magic dynamic registration going on
> in linker sets / constructors inside libbnxtre? Please explain the why
> in the commit message.

Sure enough, a peek at contrib/ofed/libbnxtre/main.c reveals a static __attribute__((constructor)) void bnxt_re_register_driver(void) which registers the driver with libibverbs. So I guess you should mention this mechanism. With that it looks ok to me.

In D54368#1243166, @markj wrote:
In D54368#1243161, @markj wrote:

I don't understand. This patch is already applied to the tree, commit 35dd53a9e1326.

Oh, it was reverted. It's the same diff as before as far as I can see, just the commit log message changed. It looks like Jessica's main question is, why exactly is it necessary to link libbnxtre:
> Secondly, this states some things, but I don’t see why this change
> follows from it. *Why* does it matter that ibv_devices and rping do not
> link against libbnxtre? If it builds, that means none of libbnxtre’s
> symbols were needed. Is there some magic dynamic registration going on
> in linker sets / constructors inside libbnxtre? Please explain the why
> in the commit message.
Sure enough, a peek at contrib/ofed/libbnxtre/main.c reveals a static __attribute__((constructor)) void bnxt_re_register_driver(void) which registers the driver with libibverbs. So I guess you should mention this mechanism. With that it looks ok to me.