Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Aug 2015 22:42:44 -0700
From:      NGie Cooper <yaneurabeya@gmail.com>
To:        Mark Johnston <markj@freebsd.org>
Cc:        freebsd-infiniband@freebsd.org, Benno Rice <benno@freebsd.org>,  Hans Petter Selasky <hps@selasky.org>, Jeff Roberson <jroberson@jroberson.net>
Subject:   Re: Enable OFED/Infiniband support in 11.0-RELEASE by default?
Message-ID:  <CAGHfRMD8ze06ekTEHgMCtAFdYqzbbP0NFw_e0=RzxCU10UhSFg@mail.gmail.com>
In-Reply-To: <20150807192930.GA88925@muskytusk>
References:  <30977F3A-59D1-4CA4-BCF6-9062A04CFF44@gmail.com> <20150807192930.GA88925@muskytusk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 7, 2015 at 12:29 PM, Mark Johnston <markj@freebsd.org> wrote:
> On Fri, Aug 07, 2015 at 11:32:00AM -0700, Garrett Cooper wrote:
>> Hi,
>>       One of the complaints from engineers at Isilon I=E2=80=99ve receiv=
ed in the past is that Infiniband/OFED stack support isn=E2=80=99t enabled =
by default in GENERIC. I would like to enable it by default in GENERIC to i=
mprove test coverage by a general audience and ensure that bugs introduced =
elsewhere (build bugs, network interface, kernel interface bugs) aren=E2=80=
=99t ignored by accident when running make tinderbox builds as it=E2=80=99s=
 not built by default.
>
> make tinderbox will build LINT kernels, which for amd64 will include the
> OFED stack.
>
> As Jason pointed out, all of the IB stack (including the Linux compat
> shims) can already be built as a KLD. Why not just make WITH_OFED the
> default on amd64 instead? That way the KLDs and userland tools will be
> built by default, and the size of the kernel needn't grow.

There are a few issues with just doing WITH_OFED, instead of building
both the sys/ofed and contrib/ofed separately:
1. sys/ofed by itself isn't incredibly useful (as we've seen
internally). Yes, not building opensm can be done if you're running it
on an IB switch, but the diagnostic tools are pretty helpful..
2. contrib/ofed has seen its fair share of bugs in the past
compilation wise (either due to interfaces or general header
compilation issues). I'd rather nip these in the bud ASAP instead of
delay them.
3. Building it just on amd64 might disguise issues with endianness,
64-bit issues, etc. Again, I want opensm, etc to be as useful on all
platforms, if possible.
Thanks!
-NGie



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMD8ze06ekTEHgMCtAFdYqzbbP0NFw_e0=RzxCU10UhSFg>