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

[sreekanth.reddy_broadcom.com]

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.

[markj]

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

[markj]

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.

[sreekanth.reddy_broadcom.com]

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.

Updated the patch description as you suggested. Thanks