Date: Fri, 7 Aug 2015 20:53:12 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: NGie Cooper <yaneurabeya@gmail.com> Cc: Mark Johnston <markj@freebsd.org>, freebsd-infiniband@freebsd.org, Benno Rice <benno@freebsd.org>, Hans Petter Selasky <hps@selasky.org> Subject: Re: Enable OFED/Infiniband support in 11.0-RELEASE by default? Message-ID: <alpine.BSF.2.20.1508072052210.6072@desktop> In-Reply-To: <CAGHfRMD8ze06ekTEHgMCtAFdYqzbbP0NFw_e0=RzxCU10UhSFg@mail.gmail.com> References: <30977F3A-59D1-4CA4-BCF6-9062A04CFF44@gmail.com> <20150807192930.GA88925@muskytusk> <CAGHfRMD8ze06ekTEHgMCtAFdYqzbbP0NFw_e0=RzxCU10UhSFg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Aug 2015, NGie Cooper wrote: > 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?ve received in the past is that Infiniband/OFED stack support isn?t enabled by default in GENERIC. I would like to enable it by default in GENERIC to improve test coverage by a general audience and ensure that bugs introduced elsewhere (build bugs, network interface, kernel interface bugs) aren?t ignored by accident when running make tinderbox builds as it?s 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. At least when I originally did the port, architectures other than x86/amd64 were not supported because I couldn't find a straightforward way to wrap the linux address handling in a way that was compatible with busdma. Jeff > Thanks! > -NGie >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1508072052210.6072>