Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
FYI: The main targets for contrib/ofed is currently [i386 and] amd64. I see there are some minor build issues for other targets, and these will be fixes as we go along. Currently contrib/ofed is not connected to the default buildworld and this should not cause any problems for the average FreeBSD user. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 02:41, Bryan Drewery wrote:
On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
On 12/07/17 01:38, Bryan Drewery wrote:
1. SUBDIR=../../somewhere else is inherently wrong.
2. Building a library from a directory named '2' is wrong.
3. Not just using proper SUBDIR_DEPEND and making all these subdirs is
not needed and complicates things MORE by splitting them all up.
4. Building a library from a directory where its real bsd.lib.mk is not
at is wrong.
5. Depending on an include directory in the Makefile.inc1 library
dependencies is simply not needed - I told you that.
Try building the COMPAT 32-bit libraries with OFED and you'll see that
this is needed!
6. Using these /0 /1 /2 /3 directories actually hurts the 'make
libraries' parallelism/dependency graph. It ends up building /1 rather
than building libibcm and libibumad directly in its graph. It creates
an indirection which adds more unneeded submake recursion.
I think this is no argument over having to maintain and update
Makefile.inc1 with all the dependencies every time there is a change or
new driver library added to OFED.
Here's the proper change to contrib/ofed/usr.lib/Makefile, it is trivial.
diff --git contrib/ofed/usr.lib/Makefile contrib/ofed/usr.lib/Makefile
index 47b97591f5b7..9c22b889fa19 100644
--- contrib/ofed/usr.lib/Makefile
+++ contrib/ofed/usr.lib/Makefile
@@ -1,13 +1,24 @@
-SUBDIR=libibcommon libibmad libibumad libibverbs libmlx4 libmthca \
- libopensm libosmcomp libosmvendor libibcm librdmacm libsdp libcxgb4
+SUBDIR= \
+ libibverbs \
+ libibcm \
+ libibumad \
+ librdmacm \
+ libibmad \
+ libosmcomp \
+ libosmvendor \
+ libcxgb4 \
+ libmlx4 \
+ libmlx5 \
+ libibnetdisc \
+ libopensm
SUBDIR_DEPEND_libcxgb4=libibverbs
SUBDIR_DEPEND_libibcm= libibverbs
-SUBDIR_DEPEND_libibmad= libibcommon libibumad
-SUBDIR_DEPEND_libibumad= libibcommon
+SUBDIR_DEPEND_libibmad=libibumad
+SUBDIR_DEPEND_libibnetdisc=libosmcomp libibmad libibumad
SUBDIR_DEPEND_libmlx4= libibverbs
-SUBDIR_DEPEND_libmthca=libibverbs
-SUBDIR_DEPEND_libosmvendor=libibumad libopensm libosmcomp
+SUBDIR_DEPEND_libmlx5= libibverbs
+SUBDIR_DEPEND_libosmvendor=libibumad
SUBDIR_DEPEND_librdmacm= libibverbs
SUBDIR_PARALLEL=
And Makefile.inc1 which is even more simple.
@@ -2365,14 +2414,12 @@ _lib_libradius= lib/libradius
.if ${MK_OFED} != "no"
_ofed_lib= contrib/ofed/usr.lib
_prebuild_libs+= contrib/ofed/usr.lib/libosmcomp
-_prebuild_libs+= contrib/ofed/usr.lib/libopensm
-_prebuild_libs+= contrib/ofed/usr.lib/libibcommon
_prebuild_libs+= contrib/ofed/usr.lib/libibverbs
+_prebuild_libs+= contrib/ofed/usr.lib/libibmad
_prebuild_libs+= contrib/ofed/usr.lib/libibumad
-contrib/ofed/usr.lib/libopensm__L: lib/libthr__L
contrib/ofed/usr.lib/libosmcomp__L: lib/libthr__L
-contrib/ofed/usr.lib/libibumad__L: contrib/ofed/usr.lib/libibcommon__L
+contrib/ofed/usr.lib/libibmad__L: contrib/ofed/usr.lib/libibumad__L
.endif
Hi,
FYI: The paths of the libraries are no longer correct.
Running:
sh tools/make_libdeps.sh $PWD
Gives this list of actual dependencies:
contrib/ofed/libcxgb4: contrib/ofed/libibverbs lib/libthr
contrib/ofed/libibcm: contrib/ofed/libibverbs
contrib/ofed/libibmad: contrib/ofed/libibumad
contrib/ofed/libibnetdisc: contrib/ofed/opensm/complib contrib/ofed/libibmad
contrib/ofed/libibumad
contrib/ofed/libmlx4: contrib/ofed/libibverbs lib/libthr
contrib/ofed/libmlx5: contrib/ofed/libibverbs lib/libthr
contrib/ofed/librdmacm: contrib/ofed/libibverbs
contrib/ofed/opensm/complib: lib/libthr
contrib/ofed/opensm/libopensm: lib/libthr
contrib/ofed/opensm/libvendor: contrib/ofed/libibumad lib/libthr
All of this information is then in turn based on the given:
LIBADD= XXX
In the respective Makefiles.
There is no need to duplicate this information. It should be pulled from
of the existing OFED Makefiles.
--HPS
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 02:32, Bryan Drewery wrote: This is what buildworld+SUBDIR_OVERRIDE is for. The following patch also mitigates the need to install libraries for build testing which I'll commit tomorrow: Nice! I will try to check it out. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 02:02, Bryan Drewery wrote:
On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
On 12/07/17 01:38, Bryan Drewery wrote:
Try building the COMPAT 32-bit libraries with OFED and you'll see that
this is needed!
No. The proper fix is to add contrib/ofed/include to the
_LC_INCDIRS.${MK_OFED:tl} list in Makefile.libcompat. Just looking at
the lib32 build you can see 'includes' is only called on a subset of
directories via _LC_INCDIRS.
The OFED includes were not there before. How does this make any
difference over depending on the include directory like I currently do?
I see Makefile.libcompat as yet another way to scatter the build details
of OFED.
I would like all the build details of OFED to stay in one place,
contrib/ofed/xxx so that future generations will understand what needs
to be updated. And then if any, Makefile.inc1 Makefile should pull /
include from there.
6. Using these /0 /1 /2 /3 directories actually hurts the 'make
libraries' parallelism/dependency graph. It ends up building /1 rather
than building libibcm and libibumad directly in its graph. It creates
an indirection which adds more unneeded submake recursion.
Please understand that /0 /1 /2 /3 is a best effort compromise, versus
parallelism and an ordered build, not having a bunch a manual and not at
least undocumented steps. I see no problem if OFED should build a little
bit slower due to this. There are plenty of libraries to build during
buildworld and the compiler should be saturated all the time, and I
don't see a real problem here.
I think this is no argument over having to maintain and update
Makefile.inc1 with all the dependencies every time there is a change or
new driver library added to OFED.
The argument is that it's how things are done. If you come up with a
brilliant solution to make Makefile.inc1 library dependencies simpler,
GREAT! But the one you have put in here is totally bogus.
Why can't you use the existing DPADD='s in the Makefiles? The only
problem I see is you need a tool to grok the location of the Makefiles
for those libraries in order to build the dependency graph?
It's fine, I'm going to rewrite it all now.
Please add me as a reviewer.
It would be nice if these utilities can be built standalone, outside the
buildworld target aswell. I've suggested adding an "all-install" variant
They mostly can, but building things directly with the current build
system simply won't create a SYSROOT or do cross-directory dependencies
properly. That's what DIRDEPS_BUILD does. Again, if you had invented
some great solution to make this simpler that would be good, but that's
not what you have here. You have simply made changes to simply build
ordering in contrib/ofed when not in buildworld, but that's not even
needed if you use the proper SUBDIR and SUBDIR_DEPEND.
to make. Having to kick a buildworld to test-build contrib/ofed is quite
overkill, and that is some of reasoning behind the current Makefile layout.
6: When a set of libraries should be built in order, it is more clean to
have 4 dependencies, than a bunch of them in my opinion.
Creating rats nest dependency lists is not proper or easier to maintain
or cleaner at all. It's wrong.
You can use the updated "tools/make_libdeps.sh" to figure this out.
The old approach with
_prebuild_libs+=
won't work :-(
I told you before how to make it work.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 01:48, Bryan Drewery wrote: 7. We don't put FreeBSD Makefiles in the same directory as contributed files. It's against the pattern. So moving contrib/ofed/usr.lib/* to contrib/ofed/*/ is wrong. It complicates future merges of contrib code. Really none of these Makefiles should be in contrib/ofed - the proper thing would be to move them out, not to inline them with the contributed code. Hi, At the moment Mellanox is maintaining this code. Importing vendor code must be merged carefully using graphical tools like "meld". There is no simple C&P at the moment. Several of the utilities in OFED use automake or cmake to build. The Makefiles for FreeBSD must be created manually. This also include the associated config.h files. All the OFED utilities have been re-organized source-wise in upstream GITs since the last OFED user-space update. I'd like the Makefiles to stay in a similar tree as the source tree, so that figuring out which Makefile pull sources from which directory is more trivial instead of having to look into each and every one of them. Finally, Mellanox has sent out several mails to infinib...@freebsd.org and curr...@freebsd.org warning and telling we are going to merge. I've waited one week extra for input, but it has all been silent. That someone now should jump and say everything is wrong with the Makefiles and build infrastructure in OFED is simply not fair. It would be really helpful to me if you could be more responsive in the few weeks behind or at least say you're busy or on vacation. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 01:50, Bryan Drewery wrote: 8. And you blew away my Makefile.depend files, which I do normally say I'll deal with, but a far simpler directory structure movement would have easily kept them and I could have updated them. But now there's not even something to start from since they were deleted for no reason I've been told that these files are automatically generated and that they are currently not in use. It should be trivial to generate new ones then ?? --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
> On 12/07/17 01:38, Bryan Drewery wrote:
>> 1. SUBDIR=../../somewhere else is inherently wrong.
>> 2. Building a library from a directory named '2' is wrong.
>> 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is
>> not needed and complicates things MORE by splitting them all up.
>> 4. Building a library from a directory where its real bsd.lib.mk is not
>> at is wrong.
>> 5. Depending on an include directory in the Makefile.inc1 library
>> dependencies is simply not needed - I told you that.
>
> Try building the COMPAT 32-bit libraries with OFED and you'll see that
> this is needed!
>
>> 6. Using these /0 /1 /2 /3 directories actually hurts the 'make
>> libraries' parallelism/dependency graph. It ends up building /1 rather
>> than building libibcm and libibumad directly in its graph. It creates
>> an indirection which adds more unneeded submake recursion.
>
> I think this is no argument over having to maintain and update
> Makefile.inc1 with all the dependencies every time there is a change or
> new driver library added to OFED.
Here's the proper change to contrib/ofed/usr.lib/Makefile, it is trivial.
> diff --git contrib/ofed/usr.lib/Makefile contrib/ofed/usr.lib/Makefile
> index 47b97591f5b7..9c22b889fa19 100644
> --- contrib/ofed/usr.lib/Makefile
> +++ contrib/ofed/usr.lib/Makefile
> @@ -1,13 +1,24 @@
> -SUBDIR=libibcommon libibmad libibumad libibverbs libmlx4 libmthca \
> - libopensm libosmcomp libosmvendor libibcm librdmacm libsdp libcxgb4
> +SUBDIR= \
> + libibverbs \
> + libibcm \
> + libibumad \
> + librdmacm \
> + libibmad \
> + libosmcomp \
> + libosmvendor \
> + libcxgb4 \
> + libmlx4 \
> + libmlx5 \
> + libibnetdisc \
> + libopensm
>
> SUBDIR_DEPEND_libcxgb4=libibverbs
> SUBDIR_DEPEND_libibcm= libibverbs
> -SUBDIR_DEPEND_libibmad= libibcommon libibumad
> -SUBDIR_DEPEND_libibumad= libibcommon
> +SUBDIR_DEPEND_libibmad=libibumad
> +SUBDIR_DEPEND_libibnetdisc=libosmcomp libibmad libibumad
> SUBDIR_DEPEND_libmlx4= libibverbs
> -SUBDIR_DEPEND_libmthca=libibverbs
> -SUBDIR_DEPEND_libosmvendor=libibumad libopensm libosmcomp
> +SUBDIR_DEPEND_libmlx5= libibverbs
> +SUBDIR_DEPEND_libosmvendor=libibumad
> SUBDIR_DEPEND_librdmacm= libibverbs
> SUBDIR_PARALLEL=
>
And Makefile.inc1 which is even more simple.
> @@ -2365,14 +2414,12 @@ _lib_libradius= lib/libradius
> .if ${MK_OFED} != "no"
> _ofed_lib= contrib/ofed/usr.lib
> _prebuild_libs+= contrib/ofed/usr.lib/libosmcomp
> -_prebuild_libs+= contrib/ofed/usr.lib/libopensm
> -_prebuild_libs+= contrib/ofed/usr.lib/libibcommon
> _prebuild_libs+= contrib/ofed/usr.lib/libibverbs
> +_prebuild_libs+= contrib/ofed/usr.lib/libibmad
> _prebuild_libs+= contrib/ofed/usr.lib/libibumad
>
> -contrib/ofed/usr.lib/libopensm__L: lib/libthr__L
> contrib/ofed/usr.lib/libosmcomp__L: lib/libthr__L
> -contrib/ofed/usr.lib/libibumad__L: contrib/ofed/usr.lib/libibcommon__L
> +contrib/ofed/usr.lib/libibmad__L: contrib/ofed/usr.lib/libibumad__L
> .endif
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
> It would be nice if these utilities can be built standalone, outside the
> buildworld target aswell. I've suggested adding an "all-install" variant
> to make. Having to kick a buildworld to test-build contrib/ofed is quite
> overkill, and that is some of reasoning behind the current Makefile layout.
This is what buildworld+SUBDIR_OVERRIDE is for. The following patch
also mitigates the need to install libraries for build testing which
I'll commit tomorrow:
> commit 7cce144e821cbf2f4e70711928a8945137700b35 (HEAD -> master)
> Author: Bryan Drewery
> Date: Wed Dec 6 17:29:57 2017 -0800
>
> Look for libraries in OBJDIR when building outside of buildworld.
>
> This allows build testing more easily without establishing a sysroot
> or installing the files.
>
> Sponsored by: Dell EMC
>
> diff --git share/mk/src.libnames.mk share/mk/src.libnames.mk
> index 2d172197ac53..fdd1a4866620 100644
> --- share/mk/src.libnames.mk
> +++ share/mk/src.libnames.mk
> @@ -359,7 +359,7 @@ LIB${_l:tu}?=
> ${LIBDESTDIR}${LIBDIR_BASE}/libprivate${_l}.a
> .endfor
>
> .for _l in ${_LIBRARIES}
> -.if ${_INTERNALLIBS:M${_l}}
> +.if ${_INTERNALLIBS:M${_l}} || !defined(SYSROOT)
> LDADD_${_l}_L+=-L${LIB${_l:tu}DIR}
> .endif
> DPADD_${_l}?= ${LIB${_l:tu}}
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:53 PM, Hans Petter Selasky wrote:
> On 12/07/17 01:38, Bryan Drewery wrote:
>> 1. SUBDIR=../../somewhere else is inherently wrong.
>> 2. Building a library from a directory named '2' is wrong.
>> 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is
>> not needed and complicates things MORE by splitting them all up.
>> 4. Building a library from a directory where its real bsd.lib.mk is not
>> at is wrong.
>> 5. Depending on an include directory in the Makefile.inc1 library
>> dependencies is simply not needed - I told you that.
>
> Try building the COMPAT 32-bit libraries with OFED and you'll see that
> this is needed!
>
No. The proper fix is to add contrib/ofed/include to the
_LC_INCDIRS.${MK_OFED:tl} list in Makefile.libcompat. Just looking at
the lib32 build you can see 'includes' is only called on a subset of
directories via _LC_INCDIRS.
>> 6. Using these /0 /1 /2 /3 directories actually hurts the 'make
>> libraries' parallelism/dependency graph. It ends up building /1 rather
>> than building libibcm and libibumad directly in its graph. It creates
>> an indirection which adds more unneeded submake recursion.
>
> I think this is no argument over having to maintain and update
> Makefile.inc1 with all the dependencies every time there is a change or
> new driver library added to OFED.
The argument is that it's how things are done. If you come up with a
brilliant solution to make Makefile.inc1 library dependencies simpler,
GREAT! But the one you have put in here is totally bogus.
>
>>
>> The whole thing needlessly obfuscates these libraries.
>>
>> It's fine, I'm going to rewrite it all now.
>
> It would be nice if these utilities can be built standalone, outside the
> buildworld target aswell. I've suggested adding an "all-install" variant
They mostly can, but building things directly with the current build
system simply won't create a SYSROOT or do cross-directory dependencies
properly. That's what DIRDEPS_BUILD does. Again, if you had invented
some great solution to make this simpler that would be good, but that's
not what you have here. You have simply made changes to simply build
ordering in contrib/ofed when not in buildworld, but that's not even
needed if you use the proper SUBDIR and SUBDIR_DEPEND.
> to make. Having to kick a buildworld to test-build contrib/ofed is quite
> overkill, and that is some of reasoning behind the current Makefile layout.
>
> 6: When a set of libraries should be built in order, it is more clean to
> have 4 dependencies, than a bunch of them in my opinion.
Creating rats nest dependency lists is not proper or easier to maintain
or cleaner at all. It's wrong.
>
> You can use the updated "tools/make_libdeps.sh" to figure this out.
>
> The old approach with
> _prebuild_libs+=
>
> won't work :-(
>
I told you before how to make it work.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 01:38, Bryan Drewery wrote: 1. SUBDIR=../../somewhere else is inherently wrong. 2. Building a library from a directory named '2' is wrong. 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is not needed and complicates things MORE by splitting them all up. 4. Building a library from a directory where its real bsd.lib.mk is not at is wrong. 5. Depending on an include directory in the Makefile.inc1 library dependencies is simply not needed - I told you that. Try building the COMPAT 32-bit libraries with OFED and you'll see that this is needed! 6. Using these /0 /1 /2 /3 directories actually hurts the 'make libraries' parallelism/dependency graph. It ends up building /1 rather than building libibcm and libibumad directly in its graph. It creates an indirection which adds more unneeded submake recursion. I think this is no argument over having to maintain and update Makefile.inc1 with all the dependencies every time there is a change or new driver library added to OFED. The whole thing needlessly obfuscates these libraries. It's fine, I'm going to rewrite it all now. It would be nice if these utilities can be built standalone, outside the buildworld target aswell. I've suggested adding an "all-install" variant to make. Having to kick a buildworld to test-build contrib/ofed is quite overkill, and that is some of reasoning behind the current Makefile layout. 6: When a set of libraries should be built in order, it is more clean to have 4 dependencies, than a bunch of them in my opinion. You can use the updated "tools/make_libdeps.sh" to figure this out. The old approach with _prebuild_libs+= won't work :-( --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:48 PM, Bryan Drewery wrote: > On 12/6/2017 4:38 PM, Bryan Drewery wrote: >> On 12/6/2017 4:28 PM, Hans Petter Selasky wrote: >>> On 12/07/17 01:10, Bryan Drewery wrote: I'm a bit speechless. Why?? The old version was 90% fine and I sent you advice on how to make it work with the new layout. >>> >>> Hi, >>> >>> I tried to listen to your advice, splitting up the Makefiles, not >>> listing every dependency. Further how the OFED libraries are linked has >>> changed. Two iterations for building the OFED libraries is not enough, >>> like before. We really need four iterations. >>> >>> I don't see how the current approach is "wrong". Can you explain a bit >>> more? >> >> 1. SUBDIR=../../somewhere else is inherently wrong. >> 2. Building a library from a directory named '2' is wrong. >> 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is >> not needed and complicates things MORE by splitting them all up. >> 4. Building a library from a directory where its real bsd.lib.mk is not >> at is wrong. >> 5. Depending on an include directory in the Makefile.inc1 library >> dependencies is simply not needed - I told you that. >> 6. Using these /0 /1 /2 /3 directories actually hurts the 'make >> libraries' parallelism/dependency graph. It ends up building /1 rather >> than building libibcm and libibumad directly in its graph. It creates >> an indirection which adds more unneeded submake recursion. >> >> The whole thing needlessly obfuscates these libraries. >> >> It's fine, I'm going to rewrite it all now. >> > > 7. We don't put FreeBSD Makefiles in the same directory as contributed > files. It's against the pattern. So moving contrib/ofed/usr.lib/* to > contrib/ofed/*/ is wrong. It complicates future merges of contrib code. > Really none of these Makefiles should be in contrib/ofed - the proper > thing would be to move them out, not to inline them with the contributed > code. > 8. And you blew away my Makefile.depend files, which I do normally say I'll deal with, but a far simpler directory structure movement would have easily kept them and I could have updated them. But now there's not even something to start from since they were deleted for no reason. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:38 PM, Bryan Drewery wrote: > On 12/6/2017 4:28 PM, Hans Petter Selasky wrote: >> On 12/07/17 01:10, Bryan Drewery wrote: >>> I'm a bit speechless. Why?? The old version was 90% fine and I sent >>> you advice on how to make it work with the new layout. >> >> Hi, >> >> I tried to listen to your advice, splitting up the Makefiles, not >> listing every dependency. Further how the OFED libraries are linked has >> changed. Two iterations for building the OFED libraries is not enough, >> like before. We really need four iterations. >> >> I don't see how the current approach is "wrong". Can you explain a bit >> more? > > 1. SUBDIR=../../somewhere else is inherently wrong. > 2. Building a library from a directory named '2' is wrong. > 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is > not needed and complicates things MORE by splitting them all up. > 4. Building a library from a directory where its real bsd.lib.mk is not > at is wrong. > 5. Depending on an include directory in the Makefile.inc1 library > dependencies is simply not needed - I told you that. > 6. Using these /0 /1 /2 /3 directories actually hurts the 'make > libraries' parallelism/dependency graph. It ends up building /1 rather > than building libibcm and libibumad directly in its graph. It creates > an indirection which adds more unneeded submake recursion. > > The whole thing needlessly obfuscates these libraries. > > It's fine, I'm going to rewrite it all now. > 7. We don't put FreeBSD Makefiles in the same directory as contributed files. It's against the pattern. So moving contrib/ofed/usr.lib/* to contrib/ofed/*/ is wrong. It complicates future merges of contrib code. Really none of these Makefiles should be in contrib/ofed - the proper thing would be to move them out, not to inline them with the contributed code. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/6/2017 4:28 PM, Hans Petter Selasky wrote: > On 12/07/17 01:10, Bryan Drewery wrote: >> I'm a bit speechless. Why?? The old version was 90% fine and I sent >> you advice on how to make it work with the new layout. > > Hi, > > I tried to listen to your advice, splitting up the Makefiles, not > listing every dependency. Further how the OFED libraries are linked has > changed. Two iterations for building the OFED libraries is not enough, > like before. We really need four iterations. > > I don't see how the current approach is "wrong". Can you explain a bit > more? 1. SUBDIR=../../somewhere else is inherently wrong. 2. Building a library from a directory named '2' is wrong. 3. Not just using proper SUBDIR_DEPEND and making all these subdirs is not needed and complicates things MORE by splitting them all up. 4. Building a library from a directory where its real bsd.lib.mk is not at is wrong. 5. Depending on an include directory in the Makefile.inc1 library dependencies is simply not needed - I told you that. 6. Using these /0 /1 /2 /3 directories actually hurts the 'make libraries' parallelism/dependency graph. It ends up building /1 rather than building libibcm and libibumad directly in its graph. It creates an indirection which adds more unneeded submake recursion. The whole thing needlessly obfuscates these libraries. It's fine, I'm going to rewrite it all now. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 12/07/17 01:10, Bryan Drewery wrote: I'm a bit speechless. Why?? The old version was 90% fine and I sent you advice on how to make it work with the new layout. Hi, I tried to listen to your advice, splitting up the Makefiles, not listing every dependency. Further how the OFED libraries are linked has changed. Two iterations for building the OFED libraries is not enough, like before. We really need four iterations. I don't see how the current approach is "wrong". Can you explain a bit more? --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/2017 6:50 AM, Hans Petter Selasky wrote:
> Modified: head/Makefile.inc1
> ==
> --- head/Makefile.inc1Fri Nov 24 14:29:32 2017(r326168)
> +++ head/Makefile.inc1Fri Nov 24 14:50:28 2017(r326169)
> @@ -2410,16 +2410,24 @@ _lib_libradius= lib/libradius
> .endif
>
> .if ${MK_OFED} != "no"
> -_ofed_lib= contrib/ofed/usr.lib
> -_prebuild_libs+= contrib/ofed/usr.lib/libosmcomp
> -_prebuild_libs+= contrib/ofed/usr.lib/libopensm
> -_prebuild_libs+= contrib/ofed/usr.lib/libibcommon
> -_prebuild_libs+= contrib/ofed/usr.lib/libibverbs
> -_prebuild_libs+= contrib/ofed/usr.lib/libibumad
> +#
> +# The OFED libraries are built in four steps
> +# as reflected below, due to interdependencies.
> +#
> +# NOTE: Depending on contrib/ofed/include is only needed for
> +# the lib32 compat build.
> +#
> +_ofed_lib= \
> +contrib/ofed/include \
> +contrib/ofed/usr.lib/0 \
> +contrib/ofed/usr.lib/1 \
> +contrib/ofed/usr.lib/2 \
> +contrib/ofed/usr.lib/3
>
> -contrib/ofed/usr.lib/libopensm__L: lib/libthr__L
> -contrib/ofed/usr.lib/libosmcomp__L: lib/libthr__L
> -contrib/ofed/usr.lib/libibumad__L: contrib/ofed/usr.lib/libibcommon__L
> +contrib/ofed/usr.lib/0__L: contrib/ofed/include__L lib/libthr__L
> +contrib/ofed/usr.lib/1__L: contrib/ofed/usr.lib/0__L
> +contrib/ofed/usr.lib/2__L: contrib/ofed/usr.lib/1__L
> +contrib/ofed/usr.lib/3__L: contrib/ofed/usr.lib/2__L
> .endif
...
> ~/git/freebsd # cat contrib/ofed/usr.lib/0/Makefile
> # $FreeBSD$
>
> SUBDIR= \
> ../../libibverbs
>
> SUBDIR_PARALLEL=
>
> .include
I'm a bit speechless. Why?? The old version was 90% fine and I sent
you advice on how to make it work with the new layout.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
[ Charset UTF-8 unsupported, converting... ] > On 11/24/17 18:35, Mark Johnston wrote: > > On Fri, Nov 24, 2017 at 06:29:25PM +0100, Hans Petter Selasky wrote: > >> On 11/24/17 18:22, Mark Johnston wrote: > >>> On Fri, Nov 24, 2017 at 06:09:25PM +0100, Hans Petter Selasky wrote: > On 11/24/17 16:00, Mark Johnston wrote: > > Are there non-trivial interoperability issues between mthca and the > > updated OFED stack? If so, could you describe them? If not, I would > > strongly prefer to retain the mthca driver, as Isilon still has plenty > > of hardware making use of it. > > Hi, > > There are no technical reasons except Mellanox hasn't focused on the > mthca driver in this upgrade. With little effort you should be able to > pull libmthca and the mthca driver from the mentioned sources and make > it work. > >>> > >>> In that case, could we please bring it back in to svn? It seems silly to > >>> remove a driver just because it's not being actively maintained: that > >>> isn't the bar for keeping drivers in FreeBSD, and I note that mthca is > >>> still present in Linux. If there is some work needed to get the kernel > >>> and userland components to compile again, I'm happy to do it; I just > >>> don't want to have to maintain an out-of-tree HCA driver when there's no > >>> good reason it can't stay in svn. > >>> > >> > >> Sure, but we probably want to put it into sys/dev/mthca instead of > >> sys/ofed/xxx . > > > > Ok. > > > >> Are you saying you want to pull it in yourself and make > >> it compile? > > > > I don't really *want* to, but I will if you don't. :) > > > > Let me discuss this at Mellanox first. I'll get back to you on Monday on > this topic. Just to add some input I would also like to see the mthca drive continue to live as a pair of them is part of my test bed here. But, I can understand these are pretty old products, and that they can be replaced for a sub $20.00 price off of ebay. (I already have a collection of Connectx-3 cards supported by mlx4 drivers.) -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/17 18:55, O. Hartmann wrote: Am Fri, 24 Nov 2017 14:50:28 + (UTC) Hans Petter Selasky schrieb: Buildworld failure: Building /usr/obj/usr/src/amd64.amd64/contrib/ofed/opensm/complib/cl_pool.o --- cl_nodenamemap.o --- /usr/src/contrib/ofed/opensm/complib/cl_nodenamemap.c:77:11: error: conflicting types for 'open_node_name_map' nn_map_t *open_node_name_map(const char *node_name_map) ^ /usr/include/infiniband/complib/cl_nodenamemap.h:57:11: note: previous declaration is here nn_map_t *open_node_name_map(char *node_name_map); ^ Hi, I think you need to "rm -rf /usr/include/infiniband" or run "make installincludes WITH_OFED=YES" first. I'm not sure how this can be avoided ... --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
Am Fri, 24 Nov 2017 14:50:28 + (UTC) Hans Petter Selasky schrieb: > Author: hselasky > Date: Fri Nov 24 14:50:28 2017 > New Revision: 326169 > URL: https://svnweb.freebsd.org/changeset/base/326169 > > Log: > RoCE/infiniband upgrade to Linux v4.9 for kernel and userspace. > > This commit merges projects/bsd_rdma_4_9 to head. > > List of kernel sources used: > > > 1) kernel sources were cloned from git://github.com/torvalds/linux.git > Top commit 69973b830859bc6529a7a0468ba0d80ee5117826 - tag: v4.9, linux-4.9 > > 2) krping was cloned from https://github.com/larrystevenwise/krping > Top commit 292a2f1abf0348285e678a82264740d52e4dcfe4 > > List of userspace sources used: > === > > 1) rdma-core was cloned from https://github.com/linux-rdma/rdma-core.git > Top commit d65138ef93af30b3ea249f3a84aa6a24ba7f8a75 > > 2) OpenSM was cloned from git://git.openfabrics.org/~halr/opensm.git > Top commit 85f841cf209f791c89a075048a907020e924528d > > 3) libibmad was cloned from git://git.openfabrics.org/~iraweiny/libibmad.git > Tag 1.3.13 with some additional patches from Mellanox. > > 4) infiniband-diags was cloned from > git://git.openfabrics.org/~iraweiny/infiniband-diags.git Tag 1.6.7 with some > additional > patches from Mellanox. > NOTES: > == > > 1) The mthca driver has been removed in kernel and in userspace. > 2) All GPLv2 only sources have been removed and where applicable > rewritten from scratch under a BSD license. > 3) List of fully supported drivers in userspace and kernel: > a) iw_cxgbe (Chelsio) > b) mlx4ib (Mellanox) > c) mlx5ib (Mellanox) > 4) WITH_OFED=YES is still required by make in order to build > OFED userspace and kernel code. > 5) Full support has been added for routable RoCE, RoCE v2. > > Sponsored by: Mellanox Technologies > > Added: > head/sys/dev/mlx5/mlx5_ib/mlx5_ib_gsi.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/dev/mlx5/mlx5_ib/mlx5_ib_gsi.c > head/sys/dev/mlx5/mlx5_ib/mlx5_ib_virt.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/dev/mlx5/mlx5_ib/mlx5_ib_virt.c > head/sys/ofed/drivers/infiniband/core/ib_addr.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_addr.c > head/sys/ofed/drivers/infiniband/core/ib_agent.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_agent.c > head/sys/ofed/drivers/infiniband/core/ib_cache.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_cache.c > head/sys/ofed/drivers/infiniband/core/ib_cm.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_cm.c > head/sys/ofed/drivers/infiniband/core/ib_cma.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_cma.c > head/sys/ofed/drivers/infiniband/core/ib_cq.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_cq.c > head/sys/ofed/drivers/infiniband/core/ib_device.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_device.c > head/sys/ofed/drivers/infiniband/core/ib_fmr_pool.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_fmr_pool.c > head/sys/ofed/drivers/infiniband/core/ib_iwcm.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_iwcm.c > head/sys/ofed/drivers/infiniband/core/ib_iwpm_msg.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_iwpm_msg.c > head/sys/ofed/drivers/infiniband/core/ib_iwpm_util.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_iwpm_util.c > head/sys/ofed/drivers/infiniband/core/ib_mad.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_mad.c > head/sys/ofed/drivers/infiniband/core/ib_mad_rmpp.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_mad_rmpp.c > head/sys/ofed/drivers/infiniband/core/ib_multicast.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_multicast.c > head/sys/ofed/drivers/infiniband/core/ib_packer.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_packer.c > head/sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c > head/sys/ofed/drivers/infiniband/core/ib_sa_query.c > - copied unchanged from r326168, > projects/bsd_rdma_4_9/sys/ofed/drivers/infiniband/core/ib_sa_query.c > head/sys/ofed/dr
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/17 18:35, Mark Johnston wrote: On Fri, Nov 24, 2017 at 06:29:25PM +0100, Hans Petter Selasky wrote: On 11/24/17 18:22, Mark Johnston wrote: On Fri, Nov 24, 2017 at 06:09:25PM +0100, Hans Petter Selasky wrote: On 11/24/17 16:00, Mark Johnston wrote: Are there non-trivial interoperability issues between mthca and the updated OFED stack? If so, could you describe them? If not, I would strongly prefer to retain the mthca driver, as Isilon still has plenty of hardware making use of it. Hi, There are no technical reasons except Mellanox hasn't focused on the mthca driver in this upgrade. With little effort you should be able to pull libmthca and the mthca driver from the mentioned sources and make it work. In that case, could we please bring it back in to svn? It seems silly to remove a driver just because it's not being actively maintained: that isn't the bar for keeping drivers in FreeBSD, and I note that mthca is still present in Linux. If there is some work needed to get the kernel and userland components to compile again, I'm happy to do it; I just don't want to have to maintain an out-of-tree HCA driver when there's no good reason it can't stay in svn. Sure, but we probably want to put it into sys/dev/mthca instead of sys/ofed/xxx . Ok. Are you saying you want to pull it in yourself and make it compile? I don't really *want* to, but I will if you don't. :) Let me discuss this at Mellanox first. I'll get back to you on Monday on this topic. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On Fri, Nov 24, 2017 at 06:29:25PM +0100, Hans Petter Selasky wrote: > On 11/24/17 18:22, Mark Johnston wrote: > > On Fri, Nov 24, 2017 at 06:09:25PM +0100, Hans Petter Selasky wrote: > >> On 11/24/17 16:00, Mark Johnston wrote: > >>> Are there non-trivial interoperability issues between mthca and the > >>> updated OFED stack? If so, could you describe them? If not, I would > >>> strongly prefer to retain the mthca driver, as Isilon still has plenty > >>> of hardware making use of it. > >> > >> Hi, > >> > >> There are no technical reasons except Mellanox hasn't focused on the > >> mthca driver in this upgrade. With little effort you should be able to > >> pull libmthca and the mthca driver from the mentioned sources and make > >> it work. > > > > In that case, could we please bring it back in to svn? It seems silly to > > remove a driver just because it's not being actively maintained: that > > isn't the bar for keeping drivers in FreeBSD, and I note that mthca is > > still present in Linux. If there is some work needed to get the kernel > > and userland components to compile again, I'm happy to do it; I just > > don't want to have to maintain an out-of-tree HCA driver when there's no > > good reason it can't stay in svn. > > > > Sure, but we probably want to put it into sys/dev/mthca instead of > sys/ofed/xxx . Ok. > Are you saying you want to pull it in yourself and make > it compile? I don't really *want* to, but I will if you don't. :) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/17 18:22, Mark Johnston wrote: On Fri, Nov 24, 2017 at 06:09:25PM +0100, Hans Petter Selasky wrote: On 11/24/17 16:00, Mark Johnston wrote: Are there non-trivial interoperability issues between mthca and the updated OFED stack? If so, could you describe them? If not, I would strongly prefer to retain the mthca driver, as Isilon still has plenty of hardware making use of it. Hi, There are no technical reasons except Mellanox hasn't focused on the mthca driver in this upgrade. With little effort you should be able to pull libmthca and the mthca driver from the mentioned sources and make it work. In that case, could we please bring it back in to svn? It seems silly to remove a driver just because it's not being actively maintained: that isn't the bar for keeping drivers in FreeBSD, and I note that mthca is still present in Linux. If there is some work needed to get the kernel and userland components to compile again, I'm happy to do it; I just don't want to have to maintain an out-of-tree HCA driver when there's no good reason it can't stay in svn. Sure, but we probably want to put it into sys/dev/mthca instead of sys/ofed/xxx . Are you saying you want to pull it in yourself and make it compile? --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On Fri, Nov 24, 2017 at 06:09:25PM +0100, Hans Petter Selasky wrote: > On 11/24/17 16:00, Mark Johnston wrote: > > Are there non-trivial interoperability issues between mthca and the > > updated OFED stack? If so, could you describe them? If not, I would > > strongly prefer to retain the mthca driver, as Isilon still has plenty > > of hardware making use of it. > > Hi, > > There are no technical reasons except Mellanox hasn't focused on the > mthca driver in this upgrade. With little effort you should be able to > pull libmthca and the mthca driver from the mentioned sources and make > it work. In that case, could we please bring it back in to svn? It seems silly to remove a driver just because it's not being actively maintained: that isn't the bar for keeping drivers in FreeBSD, and I note that mthca is still present in Linux. If there is some work needed to get the kernel and userland components to compile again, I'm happy to do it; I just don't want to have to maintain an out-of-tree HCA driver when there's no good reason it can't stay in svn. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/17 16:00, Mark Johnston wrote: Are there non-trivial interoperability issues between mthca and the updated OFED stack? If so, could you describe them? If not, I would strongly prefer to retain the mthca driver, as Isilon still has plenty of hardware making use of it. Hi, There are no technical reasons except Mellanox hasn't focused on the mthca driver in this upgrade. With little effort you should be able to pull libmthca and the mthca driver from the mentioned sources and make it work. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On 11/24/17 16:00, Mark Johnston wrote: Are there non-trivial interoperability issues between mthca and the updated OFED stack? If so, could you describe them? If not, I would strongly prefer to retain the mthca driver, as Isilon still has plenty of hardware making use of it. Hi, There are no technical reasons except Mellanox hasn't focused on the mthca driver in this upgrade. With little effort you should be able to pull libmthca and the mthca driver from the mentioned sources and make it work. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r326169 - in head: . contrib/ofed lib/libc/locale share/mk sys/amd64/amd64 sys/amd64/conf sys/conf sys/contrib/rdma/krping sys/dev/cxgbe sys/dev/cxgbe/common sys/dev/cxgbe/iw_cxgbe sys
On Fri, Nov 24, 2017 at 02:50:28PM +, Hans Petter Selasky wrote: > Author: hselasky > Date: Fri Nov 24 14:50:28 2017 > New Revision: 326169 > URL: https://svnweb.freebsd.org/changeset/base/326169 > > Log: > RoCE/infiniband upgrade to Linux v4.9 for kernel and userspace. Nice! > > This commit merges projects/bsd_rdma_4_9 to head. > > List of kernel sources used: > > > 1) kernel sources were cloned from git://github.com/torvalds/linux.git > Top commit 69973b830859bc6529a7a0468ba0d80ee5117826 - tag: v4.9, linux-4.9 > > 2) krping was cloned from https://github.com/larrystevenwise/krping > Top commit 292a2f1abf0348285e678a82264740d52e4dcfe4 > > List of userspace sources used: > === > > 1) rdma-core was cloned from https://github.com/linux-rdma/rdma-core.git > Top commit d65138ef93af30b3ea249f3a84aa6a24ba7f8a75 > > 2) OpenSM was cloned from git://git.openfabrics.org/~halr/opensm.git > Top commit 85f841cf209f791c89a075048a907020e924528d > > 3) libibmad was cloned from git://git.openfabrics.org/~iraweiny/libibmad.git > Tag 1.3.13 with some additional patches from Mellanox. > > 4) infiniband-diags was cloned from > git://git.openfabrics.org/~iraweiny/infiniband-diags.git > Tag 1.6.7 with some additional patches from Mellanox. > > NOTES: > == > > 1) The mthca driver has been removed in kernel and in userspace. Are there non-trivial interoperability issues between mthca and the updated OFED stack? If so, could you describe them? If not, I would strongly prefer to retain the mthca driver, as Isilon still has plenty of hardware making use of it. > 2) All GPLv2 only sources have been removed and where applicable > rewritten from scratch under a BSD license. > 3) List of fully supported drivers in userspace and kernel: > a) iw_cxgbe (Chelsio) > b) mlx4ib (Mellanox) > c) mlx5ib (Mellanox) > 4) WITH_OFED=YES is still required by make in order to build > OFED userspace and kernel code. > 5) Full support has been added for routable RoCE, RoCE v2. > > Sponsored by: Mellanox Technologies ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
