[HEADS UP] - OFED/RDMA stack update

[Konstantin Belousov]

On Mon, Feb 26, 2018 at 02:21:39PM -0800, Navdeep Parhar wrote:
> +freebsd-arch@
> 
> Hi Meny,
> 
> Can you please post the KPI/KBI analysis that you generated to some
> public location and provide a link here?  A straight MFC would be a
> major break of KPI/KBI in -STABLE and the options we're looking at are:
I put the report at
https://kib.kiev.ua/kib/ibcore_11_to_11_merged_compat_report.html

> 
> a) Ignore the breakage and let downstream consumers deal with the
> fallout.  This obviously isn't ideal in a -STABLE branch.
> 
> b) Provide compat shims to at least preserve the KPI.  One challenge is
> that the changes include functions with the same name but different
> signature/behavior.  See, for example, ib_create_cq in Meny's list once
> he publishes it.
Project did handled similar issues already.  One of the approaches is to
renname the ib_create_cq with the new signature to ib_create_cq_n12 and
check for (e.g.) _WANT_NEW_OFED symbol and to select one or another:
#ifdef _WANT_NEW_OFED
#define ib_create_cq(new args there) ib_create_cq_n21(new args there)
#else
#define ib_create_cq (ib_create_cq)
#endif

Then ULP that wants new KPI defines _WANT_NEW_OFED.

> 
> c) Have two versions of the OFED interfaces in 11-STABLE and not break
> existing downstream consumers at all.
It is possible to make them loadable simultaneously as modules, but it
is quite confusing to users, because Mellanox clearly wants mlx5_ib and
mlx4_ib to work only with new OFED, while cxgbe would use old OFED ?

Also, either we would need to mess with the ibcore.ko module name, or
with version.  I am not sure that our module handling is robust enough
to make the version trick possible.

> 
> I've reached out to users that I know of and know will be affected.
> If you use OFED and FreeBSD 11 this would be a good time to weigh
> in with your thoughts, ideas, concerns etc..