[ANNOUNCE] OFED 4.8-rc2 release is available

[ANNOUNCE] OFED 4.8-rc2 release is available

[Vladimir Sokolovsky]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[richard Croucher]

[-- 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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Jim Foraker]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Coulter, Susan K]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Paul Grun]

>
>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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Doug Ledford]

[-- 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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Leon Romanovsky]

[-- 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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Leon Romanovsky]

[-- 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 --]

RE: [ANNOUNCE] OFED 4.8-rc2 release is available

[Hefty, Sean]

> 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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Jason Gunthorpe]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Woodruff, Robert J]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Christoph Hellwig]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Woodruff, Robert J]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Christoph Hellwig]

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

Re: [ANNOUNCE] OFED 4.8-rc2 release is available

[Christoph Hellwig]

> - 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

[ANNOUNCE] OFED 4.8-rc2 release is available

[Vladimir Sokolovsky]

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