* [ANNOUNCE] OFED 4.8-rc2 release is available @ 2017-04-26 12:46 Vladimir Sokolovsky [not found] ` <590096A3.5090107-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Vladimir Sokolovsky @ 2017-04-26 12:46 UTC (permalink / raw) To: ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA Hi, OFED-4.8-rc2 is available at: http://openfabrics.org/downloads/OFED/ofed-4.8/OFED-4.8-rc2.tgz To get BUILD_ID run ofed_info Please report any issues in bugzilla http://bugs.openfabrics.org/bugzilla/ for OFED 4.8 Release notes: https://openfabrics.org/downloads/OFED/release_notes/OFED_4.8-rc2_release_notes OFED-4.8-rc2 Main Changes from OFED 4.8-rc1 ------------------------------------------------------------------------------- 1. compat-rdma: - iw_cxgb4: Guard against null cm_id in dump_ep/qp - Xeon Phi updates - Fixes for i40iw which have been included in kernels > 4.8 - Updated 0003-add-the-ibp-client-and-server-drivers.patch 2. Updated packages: - rdma-core v13 - libfabric-1.4.1 - fabtests-1.4.1 - libibscif-1.1.3 Regards, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <590096A3.5090107-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <590096A3.5090107-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> @ 2017-04-27 7:06 ` Christoph Hellwig [not found] ` <20170427070657.GA13585-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2017-04-27 7:06 UTC (permalink / raw) To: Vladimir Sokolovsky Cc: ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma-u79uwXL29TY76Z2rM5mHXA > - Xeon Phi updates This driver seems to never have been posted on linux-rdma, neither for the kernel, nor for rdma-core. How did it end up in your backports? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170427070657.GA13585-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170427070657.GA13585-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> @ 2017-05-04 8:49 ` Christoph Hellwig [not found] ` <20170504084933.GA1359-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2017-05-04 8:49 UTC (permalink / raw) To: Vladimir Sokolovsky Cc: ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma-u79uwXL29TY76Z2rM5mHXA On Thu, Apr 27, 2017 at 12:06:57AM -0700, Christoph Hellwig wrote: > > - Xeon Phi updates > > This driver seems to never have been posted on linux-rdma, neither > for the kernel, nor for rdma-core. How did it end up in your backports? ping? How does OFED manage to include hardware support (for a long time apparently!) that's never seen any upstream exposure? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170504084933.GA1359-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504084933.GA1359-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> @ 2017-05-04 14:28 ` Woodruff, Robert J [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Woodruff, Robert J @ 2017-05-04 14:28 UTC (permalink / raw) To: Christoph Hellwig, Vladimir Sokolovsky Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 Christoph wrote, >ping? How does OFED manage to include hardware support (for a long time >apparently!) that's never seen any upstream exposure? OFED allows code that is not upstream to be included as technology preview (not built by default) to allow people to use it. In the case of the Xeon-Phi code that uses peer to peer PCI transfers, it is not clear the Linux community would every accept it the way it is now. I saw on the list a year or so back some patches that Mellanox submitted to allow support for PCI peer to peer transfers like what the Xeon Phi code needs, and they got puked all over. So until that gets all worked out in Linux, I suspect this code will have to stay out of tree. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-05-04 14:50 ` Christoph Hellwig [not found] ` <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 15:30 ` Jason Gunthorpe 1 sibling, 1 reply; 24+ messages in thread From: Christoph Hellwig @ 2017-05-04 14:50 UTC (permalink / raw) To: Woodruff, Robert J Cc: Christoph Hellwig, Vladimir Sokolovsky, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma-u79uwXL29TY76Z2rM5mHXA So in plain words: Intel abuses their influence in OFED to ship crap that has absolutely no chance to get upstream in the current form instead of working with the community to improve infrastructure. That's exactly what I guessed, thanks for confirming. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> @ 2017-05-04 15:08 ` Woodruff, Robert J 2017-05-04 17:19 ` Hefty, Sean 2017-05-04 18:15 ` Leon Romanovsky 2 siblings, 0 replies; 24+ messages in thread From: Woodruff, Robert J @ 2017-05-04 15:08 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 Just because the code is not upstream does not mean it is crap, it just might be coded in a way that the kernel people would like done differently. Nvidia drivers are not upstream either, but lots of people use them. -----Original Message----- From: Christoph Hellwig [mailto:hch@infradead.org] Sent: Thursday, May 04, 2017 7:50 AM To: Woodruff, Robert J <robert.j.woodruff@intel.com> Cc: Christoph Hellwig <hch@infradead.org>; Vladimir Sokolovsky <vlad@dev.mellanox.co.il>; ewg@lists.openfabrics.org; linux-rdma@vger.kernel.org Subject: Re: [ANNOUNCE] OFED 4.8-rc2 release is available So in plain words: Intel abuses their influence in OFED to ship crap that has absolutely no chance to get upstream in the current form instead of working with the community to improve infrastructure. That's exactly what I guessed, thanks for confirming. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 15:08 ` Woodruff, Robert J @ 2017-05-04 17:19 ` Hefty, Sean [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199E1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> [not found] ` <e69349c0-02d0-9266-b5aa-247192e5a46c@redhat.com> 2017-05-04 18:15 ` Leon Romanovsky 2 siblings, 2 replies; 24+ messages in thread From: Hefty, Sean @ 2017-05-04 17:19 UTC (permalink / raw) To: Christoph Hellwig, Woodruff, Robert J Cc: Vladimir Sokolovsky, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma-u79uwXL29TY76Z2rM5mHXA > So in plain words: Intel abuses their influence in OFED to ship crap > that has absolutely no chance to get upstream in the current form > instead of working with the community to improve infrastructure. > > That's exactly what I guessed, thanks for confirming. OFED is a software product of OFA, not Linux. OFA can put anything that they want in it. Why do you even care? It's no different than Intel or Mellanox or any other company shipping out of tree software. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB1199E1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199E1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-05-04 18:07 ` Leon Romanovsky 0 siblings, 0 replies; 24+ messages in thread From: Leon Romanovsky @ 2017-05-04 18:07 UTC (permalink / raw) To: Hefty, Sean Cc: Christoph Hellwig, Woodruff, Robert J, Vladimir Sokolovsky, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 965 bytes --] On Thu, May 04, 2017 at 05:19:47PM +0000, Hefty, Sean wrote: > > So in plain words: Intel abuses their influence in OFED to ship crap > > that has absolutely no chance to get upstream in the current form > > instead of working with the community to improve infrastructure. > > > > That's exactly what I guessed, thanks for confirming. > > OFED is a software product of OFA, not Linux. OFA can put anything that they want in it. Why do you even care? It's no different than Intel or Mellanox or any other company shipping out of tree software. It is different. Mellanox doesn't claim that MLNX_OFED is official source package for OpenFabrics Alliance and their members. https://www.openfabrics.org/index.php/openfabrics-software.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <e69349c0-02d0-9266-b5aa-247192e5a46c@redhat.com>]
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB119B66@ORSMSX109.amr.corp.intel.com>]
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB119B66-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB119B66-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-05-04 18:58 ` Doug Ledford 0 siblings, 0 replies; 24+ messages in thread From: Doug Ledford @ 2017-05-04 18:58 UTC (permalink / raw) To: Hefty, Sean, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5, linux-rdma [-- Attachment #1.1.1: Type: text/plain, Size: 2755 bytes --] [linux-rdma@ was accidentally dropped on my email, so readding it on this response] On 5/4/2017 2:44 PM, Hefty, Sean wrote: >>> OFED is a software product of OFA, not Linux. OFA can put anything >>> that they want in it. Why do you even care? It's no different than >>> Intel or Mellanox or any other company shipping out of tree >>> software. >> >> The primary answer to your question depends on whether or not the >> software will ever be upstreamed. If it will, then it really should >> go >> there first and not later, and the reason is well exemplified by what >> happened with XRC where the version that landed in OFED and the >> version >> that landed in upstream were two totally different things, and users >> had >> to go back and fix up all their code because of the difference once it >> finally did land upstream. It's not nice to put users in that >> position >> again, and this does sound like it might end up going down that exact >> road since upstream is pursuing ways of doing peer to peer PCI >> operations and such without any input from the Xeon Phi folks. > > I'm not defending whatever business decisions any organization (including a multi-company non-profit like OFA) wants to make wrt their software distributions. I'm claiming that that's their decision. > I'm not sure I agree with that position. A company has the right to decide for themselves what to do. An organization like the OFA is different, in that it is based upon a collective agreement entered into by multiple parties with certain specific stated intents and goals written out in bylaws (although we all know the OFA is already in violation of those at the moment, let's just assume they aren't for the purposes of this conversation). If the organization then takes to violating those bylaws, it essentially becomes in breach of contract to itself and all members that originally agreed to those bylaws to my lay persons legal mind. I would say that does give people (at a minimum, any member of the organization who entered into this agreement under different pretenses, but possibly also to non-member entities affected by the actions of the organization) grounds to complain. But all that aside, the OFA at least has a pretense of wanting to get along with the upstream linux community. As long as they want to preserve that relationship, then they should listen when the community has something to say. It might well be their decision, but the ramifications of that decision might sabotage their other interests. -- Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 15:08 ` Woodruff, Robert J 2017-05-04 17:19 ` Hefty, Sean @ 2017-05-04 18:15 ` Leon Romanovsky 2 siblings, 0 replies; 24+ messages in thread From: Leon Romanovsky @ 2017-05-04 18:15 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 [-- Attachment #1.1: Type: text/plain, Size: 642 bytes --] On Thu, May 04, 2017 at 07:50:26AM -0700, Christoph Hellwig wrote: > So in plain words: Intel abuses their influence in OFED to ship crap > that has absolutely no chance to get upstream in the current form > instead of working with the community to improve infrastructure. > > That's exactly what I guessed, thanks for confirming. Yeah, it is great example why OFA, OFED and all their OF* groups should disappear. > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 14:50 ` Christoph Hellwig @ 2017-05-04 15:30 ` Jason Gunthorpe [not found] ` <20170504153003.GA854-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 1 sibling, 1 reply; 24+ messages in thread From: Jason Gunthorpe @ 2017-05-04 15:30 UTC (permalink / raw) To: Woodruff, Robert J Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 On Thu, May 04, 2017 at 02:28:26PM +0000, Woodruff, Robert J wrote: > Christoph wrote, > >ping? How does OFED manage to include hardware support (for a long time > >apparently!) that's never seen any upstream exposure? > > OFED allows code that is not upstream to be included as technology > preview (not built by default) to allow people to use it. In the > case of the Xeon-Phi code that uses peer to peer PCI transfers, it > is not clear the Linux community would every accept it the way it is > now. .. and yet I haven't really seen that group in Intel participating in the p2p discussions to design something that is mergable.. This is exactly why we so strongly discourage this out of tree stuff - getting something unmergable in OFED is *NOT* Job Done, Time to Go Home. Down this path just creates another Lustre mess. Dan Williams <dan.j.williams@intel.com> has been actively participating in the p2p discussions, perhaps you can arrange some internal collaboration.. Jason _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170504153003.GA854-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* RE: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504153003.GA854-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> @ 2017-05-04 17:34 ` Hefty, Sean [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Hefty, Sean @ 2017-05-04 17:34 UTC (permalink / raw) To: Jason Gunthorpe, Woodruff, Robert J Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 > This is exactly why we so strongly discourage this out of tree stuff - > getting something unmergable in OFED is *NOT* Job Done, Time to Go > Home. Down this path just creates another Lustre mess. Actually, this may be 'job done'. No individual or company is obligated to provide upstream software for any of their hardware. OFA decides what to ship in their software products, not the greater linux kernel community. Individual companies can decide if out of tree maintenance is more cost effective than trying to merge code upstream. Because that's what this ultimately comes down to. IMO, the only people who have legitimate complaints here are those people running Xeon Phi with Mellanox HCAs who are being forced to use OFED, rather than upstream code. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-05-04 17:41 ` Jason Gunthorpe [not found] ` <20170504174105.GB20449-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2017-05-04 18:40 ` Doug Ledford 2017-05-05 3:42 ` Jim Foraker 2 siblings, 1 reply; 24+ messages in thread From: Jason Gunthorpe @ 2017-05-04 17:41 UTC (permalink / raw) To: Hefty, Sean Cc: Woodruff, Robert J, Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 On Thu, May 04, 2017 at 05:34:35PM +0000, Hefty, Sean wrote: > > This is exactly why we so strongly discourage this out of tree stuff - > > getting something unmergable in OFED is *NOT* Job Done, Time to Go > > Home. Down this path just creates another Lustre mess. > > Actually, this may be 'job done'. No individual or company is > obligated to provide upstream software for any of their hardware. > OFA decides what to ship in their software products, not the greater > linux kernel community. The founding imputus for OFA was to get this RDMA code upstream, so OFA should not be spending their resources supporting non-upstream works. > Individual companies can decide if out of tree maintenance is more > cost effective than trying to merge code upstream. Because that's > what this ultimately comes down to. Sure. Outside the OFA and its works please. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170504174105.GB20449-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504174105.GB20449-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> @ 2017-05-04 19:07 ` Paul Grun [not found] ` <BN6PR11MB139465918AC8DFAAB56030B6B2EA0-1gF2/dm/6VsyQw8Ag4AtH5PPoyLQLiKMvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Paul Grun @ 2017-05-04 19:07 UTC (permalink / raw) To: Jason Gunthorpe, Hefty, Sean Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 > >The founding imputus for OFA was to get this RDMA code upstream, so OFA >should not be spending their resources supporting non-upstream works. > > >Jason >-- That's actually not true. The founding impetus was to prevent the nascent InfiniBand industry from fracturing under the weight of multiple software implementations of the verbs semantics described in the IB specs. The solution to that was to provide a single software stack provided by the Alliance. -Paul _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <BN6PR11MB139465918AC8DFAAB56030B6B2EA0-1gF2/dm/6VsyQw8Ag4AtH5PPoyLQLiKMvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <BN6PR11MB139465918AC8DFAAB56030B6B2EA0-1gF2/dm/6VsyQw8Ag4AtH5PPoyLQLiKMvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> @ 2017-05-04 20:17 ` Jason Gunthorpe [not found] ` <20170504201721.GA24298-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Jason Gunthorpe @ 2017-05-04 20:17 UTC (permalink / raw) To: Paul Grun Cc: Hefty, Sean, Woodruff, Robert J, Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 On Thu, May 04, 2017 at 07:07:02PM +0000, Paul Grun wrote: > >The founding imputus for OFA was to get this RDMA code upstream, so OFA > >should not be spending their resources supporting non-upstream works. > > That's actually not true. The founding impetus was to prevent the > nascent InfiniBand industry from fracturing under the weight of > multiple software implementations of the verbs semantics described > in the IB specs. The solution to that was to provide a single > software stack provided by the Alliance. I think you are splitting hairs, from the start alliance members focused their efforts upstream (eg Roland getting Linus to accept drivers/infiniband). Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20170504201721.GA24298-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504201721.GA24298-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> @ 2017-05-04 23:47 ` Coulter, Susan K 2017-05-05 0:05 ` [ewg] " Coulter, Susan K 1 sibling, 0 replies; 24+ messages in thread From: Coulter, Susan K @ 2017-05-04 23:47 UTC (permalink / raw) To: Jason Gunthorpe, Paul Grun Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 The unpleasant fact is that the OFA has not been deeply involved, as an organization, in the development and distribution of OFED. That may seem counter-intuitive, and it is certainly not appropriate, but it is the raw truth. The EWG manages, tests, and releases OFED versions. Until recently, that was all done without official review or approval from the larger OFA constituency. There are many issues the OFA needs to get straight if it is to continue to contribute to the community in a positive way. ( and I fully acccept some folks would posit that the OFA has never contributed in a positive way ) This is one of them. ________________________________________ From: linux-rdma-owner@vger.kernel.org <linux-rdma-owner@vger.kernel.org> on behalf of Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Sent: Thursday, May 4, 2017 2:17 PM To: Paul Grun Cc: Hefty, Sean; Woodruff, Robert J; Christoph Hellwig; linux-rdma@vger.kernel.org; ewg@lists.openfabrics.org Subject: Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available On Thu, May 04, 2017 at 07:07:02PM +0000, Paul Grun wrote: > >The founding imputus for OFA was to get this RDMA code upstream, so OFA > >should not be spending their resources supporting non-upstream works. > > That's actually not true. The founding impetus was to prevent the > nascent InfiniBand industry from fracturing under the weight of > multiple software implementations of the verbs semantics described > in the IB specs. The solution to that was to provide a single > software stack provided by the Alliance. I think you are splitting hairs, from the start alliance members focused their efforts upstream (eg Roland getting Linus to accept drivers/infiniband). Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <20170504201721.GA24298-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2017-05-04 23:47 ` Coulter, Susan K @ 2017-05-05 0:05 ` Coulter, Susan K 1 sibling, 0 replies; 24+ messages in thread From: Coulter, Susan K @ 2017-05-05 0:05 UTC (permalink / raw) To: linux-rdma-u79uwXL29TY76Z2rM5mHXA ________________________________________ From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> on behalf of Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Sent: Thursday, May 4, 2017 2:17 PM To: Paul Grun Cc: Hefty, Sean; Woodruff, Robert J; Christoph Hellwig; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org Subject: Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available On Thu, May 04, 2017 at 07:07:02PM +0000, Paul Grun wrote: > >The founding imputus for OFA was to get this RDMA code upstream, so OFA > >should not be spending their resources supporting non-upstream works. > > That's actually not true. The founding impetus was to prevent the > nascent InfiniBand industry from fracturing under the weight of > multiple software implementations of the verbs semantics described > in the IB specs. The solution to that was to provide a single > software stack provided by the Alliance. I think you are splitting hairs, from the start alliance members focused their efforts upstream (eg Roland getting Linus to accept drivers/infiniband). Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 17:41 ` Jason Gunthorpe @ 2017-05-04 18:40 ` Doug Ledford [not found] ` <75ebb17e-cec3-6605-2a2f-d2533e95a5ec-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-05-05 3:42 ` Jim Foraker 2 siblings, 1 reply; 24+ messages in thread From: Doug Ledford @ 2017-05-04 18:40 UTC (permalink / raw) To: Hefty, Sean, Jason Gunthorpe, Woodruff, Robert J Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 [-- Attachment #1.1: Type: text/plain, Size: 2270 bytes --] On 5/4/2017 1:34 PM, Hefty, Sean wrote: >> This is exactly why we so strongly discourage this out of tree >> stuff - getting something unmergable in OFED is *NOT* Job Done, >> Time to Go Home. Down this path just creates another Lustre mess. > > Actually, this may be 'job done'. No individual or company is > obligated to provide upstream software for any of their hardware. Very true, but in that case you would expect Intel to be shipping the software, not OFA. Much like they already do with their compiler, their MPI, etc. > OFA decides what to ship in their software products, not the greater > linux kernel community. Individual companies can decide if out of > tree maintenance is more cost effective than trying to merge code > upstream. Because that's what this ultimately comes down to. The OFA has already learned their lesson once with XRC. I wonder if they are getting ready to get hit with another lesson over this. The issue is if the OFA ships an API and it isn't upstream, then that API needs to legitimately be a private, should never conflict with upstream API. If upstream then implements the same thing in a different way and users are exposed to the rather unpleasant choice of code to OFA's API or to upstream's API for the same thing, it creates a schism in the user's code base around what API to use/support. This is entirely contrary to the OFA's stated goals about the end user experience of people using their RDMA software. So Intel can certainly make any cost analysis they want about their hardware and the software to support it, but the OFA is not Intel's personal software distributor and the OFA must look at other, bigger picture issues than Intel. > IMO, the only people who have legitimate complaints here are those > people running Xeon Phi with Mellanox HCAs who are being forced to > use OFED, rather than upstream code. I suspect there are legitimate grounds to complain about the fact that it is shipped in the OFA OFED and not limited to an Intel OFED derivative similar to Mellanox OFED. -- Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <75ebb17e-cec3-6605-2a2f-d2533e95a5ec-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* RE: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <75ebb17e-cec3-6605-2a2f-d2533e95a5ec-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2017-05-04 19:14 ` Woodruff, Robert J [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Woodruff, Robert J @ 2017-05-04 19:14 UTC (permalink / raw) To: Doug Ledford, Hefty, Sean, Jason Gunthorpe Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 Doug Ledford wrote, >The OFA has already learned their lesson once with XRC. I wonder if they are getting ready to get hit with another lesson over this. The issue is if the OFA ships an API and it isn't upstream, then that API needs to legitimately be a >private, should never conflict with upstream API. If upstream then implements the same thing in a different way and users are exposed to the rather unpleasant choice of code to OFA's API or to upstream's API for the same thing, it >creates a schism in the user's code base around what API to use/support. This is entirely contrary to the OFA's stated goals about the end user experience of people using their RDMA software. So Intel can certainly make any cost >analysis they want about their hardware and the software to support it, but the OFA is not Intel's personal software distributor and the OFA must look at other, bigger picture issues than Intel. The Xeon-Phi code is somewhat different than what happened in the past with XRC. In the case of XRC, it was integrated into the base OFED package and built-in by default. For the Xeon-Phi code, it is clearly marked as a technology preview and is not even compiled in at all unless specifically enabled. This is not too terribly different than the experimental branches that the kernel has. Also, the Xeon-Phi code does not add any new APIs. It simply implements a driver set and library, thus there is no risk in someone coding to an API in OFED that gets totally changed once it gets upstream. The EWG charter allows code that is not upstream to be added as a technology preview. This allows people that want it, to try it out and use it. I personally do not see a reason to change that. You may not like what we are doing, and if you are an OFA promoter member, you could ask for a vote of the board to change the bylaws to prevent it. In the absence of that, you really do not have a say in the matter. ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> @ 2017-05-04 20:14 ` Doug Ledford [not found] ` <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Doug Ledford @ 2017-05-04 20:14 UTC (permalink / raw) To: Woodruff, Robert J, Hefty, Sean, Jason Gunthorpe Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 [-- Attachment #1.1: Type: text/plain, Size: 3449 bytes --] On 5/4/2017 3:14 PM, Woodruff, Robert J wrote: > Doug Ledford wrote, >> The OFA has already learned their lesson once with XRC. I wonder >> if they are getting ready to get hit with another lesson over this. >> The issue is if the OFA ships an API and it isn't upstream, then >> that API needs to legitimately be a >private, should never conflict >> with upstream API. If upstream then implements the same thing in a >> different way and users are exposed to the rather unpleasant choice >> of code to OFA's API or to upstream's API for the same thing, it >> >creates a schism in the user's code base around what API to >> use/support. This is entirely contrary to the OFA's stated goals >> about the end user experience of people using their RDMA software. >> So Intel can certainly make any cost >analysis they want about >> their hardware and the software to support it, but the OFA is not >> Intel's personal software distributor and the OFA must look at >> other, bigger picture issues than Intel. > > The Xeon-Phi code is somewhat different than what happened in the > past with XRC. In the case of XRC, it was integrated into the base > OFED package and built-in by default. For the Xeon-Phi code, it is > clearly marked as a technology preview and is not even compiled in at > all unless specifically enabled. This is not too terribly different > than the experimental branches that the kernel has. Also, the > Xeon-Phi code does not add any new APIs. It implements a new kernel internal API, yes? > It simply implements a > driver set and library, thus there is no risk in someone coding to an > API in OFED that gets totally changed once it gets upstream. I'm not sure I understand your statement here Woody. If there's no API, then how do people even use the hardware? Or are you saying that the API is in the library, and that API can be preserved even if the underlying driver implementation is changed to match whatever upstream might implement instead of what you already have implemented? > you really do not have a say in the matter. Nope. I don't. But, as I pointed out in my other email, if relationships matter, then whether or not someone has a say does not negate the need to listen. Personally, I haven't really investigated this code so I'm not going to argue against the fact that the OFA ships it, other than what I have already which is that it has been a stated goal of the OFA to foster a unified code base, so collaborating with upstream is generally necessary. If you are saying that the Xeon Phi support is implemented in a library (like nVidia's CUDA support) that insulates the end user from a possible fracture if upstream implements things differently, then that mostly settles my concerns. I still think it would be best if the Xeon Phi people collaborated with upstream on the kernel internal Peer to Peer PCI API as that's evidently a requirement of the Xeon Phi library? It is conceivably possible failure to collaborate could in fact break the Xeon Phi library if they simply don't implement something the library has a hard requirement on. But that's outside of my particular wheel house so I'm just suggesting that it might be a wise thing to do. -- Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> GPG Key ID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 884 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* RE: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> @ 2017-05-04 20:54 ` Woodruff, Robert J 0 siblings, 0 replies; 24+ messages in thread From: Woodruff, Robert J @ 2017-05-04 20:54 UTC (permalink / raw) To: Doug Ledford, Hefty, Sean, Jason Gunthorpe Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 Doug wrote, >I'm not sure I understand your statement here Woody. If there's no API, then how do people even use the hardware? Or are you saying that the API is in the library, and that API can be preserved even if the underlying driver >implementation is changed to match whatever upstream might implement instead of what you already have implemented? The code that goes into OFED does not implement any new APIs or changes to existing verbs APIs. It implements drivers and user-space libraries that plug into the user and kernel space core and emulate the standard RDMA verbs. Users use it the same way they use any RDMA device in OFED, through libibverbs. Although under the covers, there is much more to it than that but from the user's point of view it looks just like an HCA that is used through the standard verbs. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 17:41 ` Jason Gunthorpe 2017-05-04 18:40 ` Doug Ledford @ 2017-05-05 3:42 ` Jim Foraker [not found] ` <e982e074-4a0a-397f-fbe2-63ff0232c56d-i2BcT+NCU+M@public.gmane.org> 2 siblings, 1 reply; 24+ messages in thread From: Jim Foraker @ 2017-05-05 3:42 UTC (permalink / raw) To: Hefty, Sean, Jason Gunthorpe, Woodruff, Robert J Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 On 05/04/2017 10:34 AM, Hefty, Sean wrote: >> This is exactly why we so strongly discourage this out of tree >> stuff - getting something unmergable in OFED is *NOT* Job Done, >> Time to Go Home. Down this path just creates another Lustre mess. > > Actually, this may be 'job done'. No individual or company is > obligated to provide upstream software for any of their hardware. > OFA decides what to ship in their software products, not the greater > linux kernel community. Individual companies can decide if out of > tree maintenance is more cost effective than trying to merge code > upstream. Because that's what this ultimately comes down to. > > IMO, the only people who have legitimate complaints here are those > people running Xeon Phi with Mellanox HCAs who are being forced to > use OFED, rather than upstream code. Apparently we've experimented with doing just this, so I'll bite. And I will say the same thing we've told every vendor repeatedly: "get your code upstream!" A vendor may weigh the cost of maintaining out-of-tree code versus upstreaming it, but as a customer, I'm more concerned about the annoyance and time wasted having to run N different software stacks on N different hardware types versus being able to use the RDMA stack from my preferred linux distribution everywhere. And the best way to get your code into the distributions is to get it upstream. I have no particular opinion on whether or not the xeon-phi driver belongs in OFED. But cloaking this conversation in talk of obligations and framers' intent misses a bigger point, which is that any code not fully upstreamed, and hence likely to be found in your user's distro, inconveniences them, increases their support costs, and makes it less likely that they will adopt your product. Jim _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <e982e074-4a0a-397f-fbe2-63ff0232c56d-i2BcT+NCU+M@public.gmane.org>]
* Re: [ANNOUNCE] OFED 4.8-rc2 release is available [not found] ` <e982e074-4a0a-397f-fbe2-63ff0232c56d-i2BcT+NCU+M@public.gmane.org> @ 2017-05-05 7:43 ` richard Croucher 0 siblings, 0 replies; 24+ messages in thread From: richard Croucher @ 2017-05-05 7:43 UTC (permalink / raw) To: Jim Foraker, Hefty, Sean, Jason Gunthorpe, Woodruff, Robert J Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA, ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5 [-- Attachment #1.1: Type: text/plain, Size: 3433 bytes --] I could not echo this point more. I principally work with Enterprise clients. None use custom kernels and all are dependent on the support provided from their Linux distro vendors. We have repeatedly ended up in finger pointing exercises where RDMA vendors insist on us using their drivers and the Linux distro vendor want us to use there's. The customer always loses in these situations. Only as an absolute last resort we will use proprietary drivers, modules and system libraries because we know it will compromise support and may hit us later. Certain vendors try to do this under the radar now replacing all sorts of distro system libraries when you innocently install their Ethernet driver. Doing it surreptitiously rather than blatantly is not the answer. Get your code into mainline and work with the major distro vendors on the backports and updates. I continually face resistance from Enterprise accounts in adopting RDMA in a more widespread manner. It's the perception of the risk raised by the Linux SA's in supporting these systems. I needs to just 'work' running only the standard distro installers to add it if it is not there by default. On Thu, 2017-05-04 at 20:42 -0700, Jim Foraker wrote: > On 05/04/2017 10:34 AM, Hefty, Sean wrote: > > > > > > > > This is exactly why we so strongly discourage this out of tree > > > stuff - getting something unmergable in OFED is *NOT* Job Done, > > > Time to Go Home. Down this path just creates another Lustre mess. > > Actually, this may be 'job done'. No individual or company is > > obligated to provide upstream software for any of their hardware. > > OFA decides what to ship in their software products, not the > > greater > > linux kernel community. Individual companies can decide if out of > > tree maintenance is more cost effective than trying to merge code > > upstream. Because that's what this ultimately comes down to. > > > > IMO, the only people who have legitimate complaints here are those > > people running Xeon Phi with Mellanox HCAs who are being forced to > > use OFED, rather than upstream code. > Apparently we've experimented with doing just this, so I'll > bite. > And I will say the same thing we've told every vendor repeatedly: > "get > your code upstream!" > A vendor may weigh the cost of maintaining out-of-tree code > versus > upstreaming it, but as a customer, I'm more concerned about the > annoyance and time wasted having to run N different software stacks > on N > different hardware types versus being able to use the RDMA stack from > my > preferred linux distribution everywhere. And the best way to get > your > code into the distributions is to get it upstream. > I have no particular opinion on whether or not the xeon-phi > driver > belongs in OFED. But cloaking this conversation in talk of > obligations > and framers' intent misses a bigger point, which is that any code > not > fully upstreamed, and hence likely to be found in your user's > distro, > inconveniences them, increases their support costs, and makes it > less > likely that they will adopt your product. > > Jim > _______________________________________________ > ewg mailing list > ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org > http://lists.openfabrics.org/mailman/listinfo/ewg -- Richard Croucher www.informatix-sol.com [-- Attachment #1.2: Type: text/html, Size: 4106 bytes --] [-- Attachment #2: Type: text/plain, Size: 140 bytes --] _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ewg ^ permalink raw reply [flat|nested] 24+ messages in thread
* [ANNOUNCE] OFED 4.8-rc2 release is available @ 2017-04-26 12:46 Vladimir Sokolovsky 0 siblings, 0 replies; 24+ messages in thread From: Vladimir Sokolovsky @ 2017-04-26 12:46 UTC (permalink / raw) To: ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA Hi, OFED-4.8-rc2 is available at: http://openfabrics.org/downloads/OFED/ofed-4.8/OFED-4.8-rc2.tgz To get BUILD_ID run ofed_info Please report any issues in bugzilla http://bugs.openfabrics.org/bugzilla/ for OFED 4.8 Release notes: https://openfabrics.org/downloads/OFED/release_notes/OFED_4.8-rc2_release_notes OFED-4.8-rc2 Main Changes from OFED 4.8-rc1 ------------------------------------------------------------------------------- 1. compat-rdma: - iw_cxgb4: Guard against null cm_id in dump_ep/qp - Xeon Phi updates - Fixes for i40iw which have been included in kernels > 4.8 - Updated 0003-add-the-ibp-client-and-server-drivers.patch 2. Updated packages: - rdma-core v13 - libfabric-1.4.1 - fabtests-1.4.1 - libibscif-1.1.3 Regards, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-05-05 7:43 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-26 12:46 [ANNOUNCE] OFED 4.8-rc2 release is available Vladimir Sokolovsky [not found] ` <590096A3.5090107-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> 2017-04-27 7:06 ` Christoph Hellwig [not found] ` <20170427070657.GA13585-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 8:49 ` Christoph Hellwig [not found] ` <20170504084933.GA1359-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 14:28 ` Woodruff, Robert J [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 14:50 ` Christoph Hellwig [not found] ` <20170504145026.GA22388-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-05-04 15:08 ` Woodruff, Robert J 2017-05-04 17:19 ` Hefty, Sean [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199E1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 18:07 ` Leon Romanovsky [not found] ` <e69349c0-02d0-9266-b5aa-247192e5a46c@redhat.com> [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB119B66@ORSMSX109.amr.corp.intel.com> [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB119B66-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 18:58 ` Doug Ledford 2017-05-04 18:15 ` Leon Romanovsky 2017-05-04 15:30 ` Jason Gunthorpe [not found] ` <20170504153003.GA854-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2017-05-04 17:34 ` [ewg] " Hefty, Sean [not found] ` <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 17:41 ` Jason Gunthorpe [not found] ` <20170504174105.GB20449-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2017-05-04 19:07 ` Paul Grun [not found] ` <BN6PR11MB139465918AC8DFAAB56030B6B2EA0-1gF2/dm/6VsyQw8Ag4AtH5PPoyLQLiKMvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> 2017-05-04 20:17 ` [ewg] " Jason Gunthorpe [not found] ` <20170504201721.GA24298-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 2017-05-04 23:47 ` Coulter, Susan K 2017-05-05 0:05 ` [ewg] " Coulter, Susan K 2017-05-04 18:40 ` Doug Ledford [not found] ` <75ebb17e-cec3-6605-2a2f-d2533e95a5ec-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-05-04 19:14 ` Woodruff, Robert J [not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> 2017-05-04 20:14 ` Doug Ledford [not found] ` <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-05-04 20:54 ` Woodruff, Robert J 2017-05-05 3:42 ` Jim Foraker [not found] ` <e982e074-4a0a-397f-fbe2-63ff0232c56d-i2BcT+NCU+M@public.gmane.org> 2017-05-05 7:43 ` richard Croucher 2017-04-26 12:46 Vladimir Sokolovsky
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.