redhat/spec: can't build ibumad on 32-bit arm
PATCH 1/1 redhat/spec: can't build ibumad on 32-bit arm
Building for 32-bit arm, things fall down, due to lack of arch-specific memory barriers.
In file included from /builddir/build/BUILD/rdma-core-12/libibumad/sysfs.c:46:0:include/infiniband/arch.h:132:2: error: #error No architecture specific memory barrier defines found!
#error No architecture specific memory barrier defines found!
--- redhat/rdma-core.spec | 1 + 1 file changed, 1 insertion(+)
redhat/rdma-core.spec +1 -0
@@ -166,6 +166,7 @@ level work required to open an RDMA connection between two machines. %package -n libibumad Summary: OpenFabrics Alliance InfiniBand umad (userspace management datagram) library +ExcludeArch: %{arm} Requires: %{name}%{?_isa} = %{version}-%{release} %description -n libibumad
Signature · 6 lines
2.10.0 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170109213944.31970-1-jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Quoted 2 lines · Jarod Wilson
Building for 32-bit arm, things fall down, due to lack of arch-specific memory barriers.
Since we now have rxe that should work on ARM I think we need to fix this upstream..
Do you have time to test some patches on ARM?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170109223108.GA10850-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Quoted 8 lines · Jason Gunthorpe
Quoted 2 lines · Jarod Wilson
Building for 32-bit arm, things fall down, due to lack of arch-specific memory barriers.
Since we now have rxe that should work on ARM I think we need to fix this upstream..
Do you have time to test some patches on ARM?
Afraid I don't have hardware. To the best of my knowledge, the only ARM systems my group has (and/or are getting soon) with RDMA hardware is all ARM64.
Signature · 6 lines
Jarod Wilson [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 0e01bfc8-333d-99dd-f7d1-024422923021-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Quoted 5 lines · Jarod Wilson
Quoted 4 lines · Jason Gunthorpe
Quoted 2 lines · Jarod Wilson
Building for 32-bit arm, things fall down, due to lack of arch-specific memory barriers.
Quoted 8 lines
Quoted 4 lines
Since we now have rxe that should work on ARM I think we need to fix this upstream..
Do you have time to test some patches on ARM?
Afraid I don't have hardware. To the best of my knowledge, the only ARM systems my group has (and/or are getting soon) with RDMA hardware is all ARM64.
RDMA hardware doesn't work in ARM so that is OK. Cross compiling is fine, ideal would be to test RXE on an arbitary ARM system, but I wouldn't call that critical.
I just don't want to setup a cross compiler for this :\
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170110161031.GB15493-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org
Quoted 8 lines
RDMA hardware doesn't work in ARM so that is OK. Cross compiling is fine, ideal would be to test RXE on an arbitary ARM system, but I wouldn't call that critical.
I just don't want to setup a cross compiler for this :\
Jason
--
Hi Jason, Doug, All,
I wanted to bring to your attention that our RDMA solution *is* working in an ARM based environment:
the Cavium ThunderX platform. This is a 64bit ARMv8 *with* cache coherency. Please keep that in mind when considering RDMA-relevant platforms.
Thanks,
Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): SN1PR07MB220756D06EA23CE46DEC11A2F8790-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org
Quoted 6 lines · Ram
Quoted 6 lines
RDMA hardware doesn't work in ARM so that is OK. Cross compiling is fine, ideal would be to test RXE on an arbitary ARM system, but I wouldn't call that critical.
I just don't want to setup a cross compiler for this :\
Quoted 8 lines
Quoted 2 lines
Jason
--Hi Jason, Doug, All,
I wanted to bring to your attention that our RDMA solution *is* working in an ARM based environment:
the Cavium ThunderX platform. This is a 64bit ARMv8 *with* cache coherency. Please keep that in mind when considering RDMA-relevant platforms.
They are referring to 32bit ARM in their discussion. AFAIK all devices in RDMA are working and supported in 64bit ARM environment.
Quoted 8 lines
Thanks,
Ram--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20170112130640.GG20392-U/[email protected]
Quoted 11 lines
Quoted 11 lines
Quoted 8 lines
RDMA hardware doesn't work in ARM so that is OK. Cross compiling is fine, ideal would be to test RXE on an arbitary ARM system, but I wouldn't call that critical.
I just don't want to setup a cross compiler for this :\
Jason
--Hi Jason, Doug, All,
Quoted 8 lines
Quoted 1 line
I wanted to bring to your attention that our RDMA solution *is* working
in an ARM based environment:
Quoted 2 lines
the Cavium ThunderX platform. This is a 64bit ARMv8 *with* cache coherency. Please keep that in mind when considering RDMA-relevant
platforms.
They are referring to 32bit ARM in their discussion. AFAIK all devices in RDMA are working and supported in 64bit ARM environment.
I understand that the thread relates to 32-bit. I wanted to make sure that it doesn't impact 64-bit, as the sentence - "RDMA hardware doesn't work in ARM " may imply that ARM doesn't support RDMA at all and that 64-bit may be dropped.
Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): SN1PR07MB2207AAD33488239E59339881F8790-mikhvbZlbf8TSoR2DauN2+FPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org
Quoted 7 lines · Ram
Quoted 2 lines
They are referring to 32bit ARM in their discussion. AFAIK all devices in RDMA are working and supported in 64bit ARM environment.
I understand that the thread relates to 32-bit. I wanted to make sure that it doesn't impact 64-bit, as the sentence - "RDMA hardware doesn't work in ARM " may imply that ARM doesn't support RDMA at all and that 64-bit may be dropped.
hhns is already 64 bit ARM only hardware, it will be supported..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Jason Gunthorpe
Quoted 2 lines · Jarod Wilson
Building for 32-bit arm, things fall down, due to lack of arch-specific memory barriers.
Since we now have rxe that should work on ARM I think we need to fix this upstream..
Do you have time to test some patches on ARM?
Looks to me that issue was introduced by:
commit 1df0888f6a736e1612ce8b054d6c17651ebd003f
Author: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Date: Fri Sep 2 12:57:57 2016 -0600
Remove most checks of __BYTE_ORDER
For a long time now endian.h has defined sane fixed with conversion macros, so lets just use them instead of rolling our own.
Also, htonll is defined in this source tree under infiniband/arch.h, so all users of that macro can just use the header.
Someday we should also get rid of all the endless wrappers..
where byte order macros are from libibverbs arch.h which also includes the memory barrier stuff.
So can't arch.h be separated out into 2 headers and have the various parts of rdma-core include one or both of these headers as needed ?
-- Hal
Quoted 6 lines
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): a1b3f6cc-2de0-8a19-18dd-182f2cb7d3e1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
Quoted 32 lines · Hal Rosenstock
Quoted 7 lines · Jason Gunthorpe
Quoted 4 lines · Jarod Wilson
Building for 32-bit arm, things fall down, due to lack of arch- specific
memory barriers.Quoted 5 lines
Since we now have rxe that should work on ARM I think we need to fix
this upstream..Do you have time to test some patches on ARM?
Looks to me that issue was introduced by:
commit
1df0888f6a736e1612ce8b054d6c17651ebd003f
Author: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Date: Fri Sep 2 12:57:57 2016 -0600Remove most checks of
__BYTE_ORDERFor a long time now
endian.hhas defined sane fixed with conversion
macros, so lets just use them instead of rolling our own.Also, htonll is defined in this source tree under
infiniband/arch.h,
so all users of that macro can just use the header.Someday we should also get rid of all the endless wrappers..
Quoted 8 lines
Signed-off-by Jason Gunthorpe <[email protected]>where byte order macros are from libibverbs
arch.hwhich also includes
the memory barrier stuff.So can't
arch.hbe separated out into 2 headers and have the various parts of rdma-core include one or both of these headers as needed ?
No, that won't help. At most it would shift where the compile breaks. When Steve Wise did the patch to add the arm64 memory barriers, we discussed on list the fact that not having a proper memory barrier define for an arch should be a fatal error, so we also made it such that without an arch specific memory barrier define, we fail the build. If you split the headers, then somewhere you are going to come to a file that needs the memory barriers defined in the headers, and when you include the header, the compile error returns. The proper fix is just to get 32bit arm defines in place.
Signature · 4 lines
Doug Ledford <[email protected]> GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Doug Ledford
file that needs the memory barriers defined in the headers, and when you include the header, the compile error returns. ??The proper fix is just to get 32bit arm defines in place.
It is a little worse than that, 32 bit ARM is not DMA coherent at all so it simply cannot work. The fix is to not compile providers that require DMA coherence on arches that cannot provide it.
Bit tricky, but almost done..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html