Re: [ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

2020-04-06 Thread Michal Kalderon 
Hi,

>From Marvell (Cavium )  we prefer to deliver our own drivers to customers,
We don't see the added value of having a common ofed release if it's just for 
drivers.

Thanks,
Michal

From: ewg  On Behalf Of Woodruff, Robert J
Sent: Saturday, April 4, 2020 1:06 AM
To: Davis, Arlin R ; Vladimir Sokolovsky 
; ewg@lists.openfabrics.org
Subject: [EXT] Re: [ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

External Email

The possible value that I see would be:


  1.  There is a bug fix or enhancement that is contained to a vendor driver 
that the vendor wants to get to a customer without having to wait for the next 
distro release.
  2.  There is a bug fix in an older distro version and the vendor wants to 
provide their customer with an updated driver that fixes the bug. Even if the 
bug fix is available in a newer distro version, some customers do not want to 
upgrade to a newer distro version just to get a bug fix for one driver.
  3.  There are bug fixes or newer features in the latest user-space rdma-core 
or other user-space packages that someone wants.

The question is, do people in the EWG want to have a common OFED-lite package 
with all those updates or would they prefer to just deliver their own updated 
drivers to their customers which they can already do without any help for the 
EWG and OFED.

Woody

From: Davis, Arlin R mailto:arlin.r.da...@intel.com>>
Sent: Friday, April 03, 2020 2:57 PM
To: Vladimir Sokolovsky 
mailto:v...@dev.mellanox.co.il>>; 
ewg@lists.openfabrics.org<mailto:ewg@lists.openfabrics.org>
Cc: Woodruff, Robert J 
mailto:robert.j.woodr...@intel.com>>
Subject: RE: OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

Yes, updated drivers would be limited the in-kernel RDMA stack from the distro 
so we could not add new features, just provide bug fixing. I tend to agree, not 
much value, but I was asked to present the option to the working group. 
Clearly, we wouldn't move any faster than the distro, especially with their new 
commitment of a 6 month "predictable release cadence".

Maybe others can see value and can comment.


From: Vladimir Sokolovsky 
mailto:v...@dev.mellanox.co.il>>
Sent: Friday, April 03, 2020 12:02 PM
To: Davis, Arlin R mailto:arlin.r.da...@intel.com>>; 
ewg@lists.openfabrics.org<mailto:ewg@lists.openfabrics.org>
Cc: Woodruff, Robert J 
mailto:robert.j.woodr...@intel.com>>
Subject: Re: OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

On 04/03/2020 09:16 PM, Davis, Arlin R wrote:
Hello,

The recommendation from the OFA board is to move to a lite weight OFED 
packaging option. This new packaging would simply update the vendors drivers, 
rebased for distro's compat_rdma kernel sub-system. It would not replace the 
entire compat-rdma sub-system with latest upstream kernel versions. Not sure 
how we handle the out of tree builds for rdma_core in user-space, we may have 
to patch and rebuild entire package.

Would this be an acceptable packaging option for your company? Would there be 
any value without latest upstream compat-rdma stack?

We will discuss this on Monday, or you can simply reply to the EWG mailing list 
with your feedback.

Thanks,

Arlin

Hi Arlin,
Can you elaborate on the meaning of "simply update the vendors drivers, rebased 
for distro's compat_rdma kernel sub-system"? Isn't it already included in 
Distros?
In most cases vendor's driver cannot be updated without updating kernel's RDMA 
infrastructure which, in turn, will require other vendors drivers to be updated 
or disabled.
It is not clear which components OFED will include... For the user space there 
are only two options: use the in-box version (which means no new features) or 
replace the in-box version by the newer upstream version as of today.

Honestly, Distros are pretty up to date with the latest upstream changes, so 
that OFED release cycle is no shorter that most of the Distros release cycle. 
So, customers can get the latest updates just by upgrading to the new Distro 
version and this way they will continue to get support by Distros' vendors.
The added value of having community OFED was to provide support of the new 
features available upstream to older versions of Linux Distributions (when 
possible). But historically it did not really happened as most of the companies 
skipped on providing backports for their device drivers. So, it looses its 
value...

Other thoughts?

Regards,
Vladimir



Join Zoom Meeting
https://zoom.us/j/722177620<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-253A-252F-252Fzoom.us-252Fj-252F722177620-26sa-3DD-26ust-3D157893717351-26usg-3DAFQjCNHhw1twJxp1EaVBxmVJQBrHNq2yfQ=DwMFAg=nKjWec2b6R0mOyPaz7xtfQ=7YunNpwaTtA-c31OjGDRlooaE_vWmAHeUXp7I6nr6Ng=9WLLDI-sFFVjohxLafIAV4goOwwQRg6NrKwqFrKk_Tk=iWPwqKH9WJG8geLKrDsCN-3nTI98zq4iC-O9yBt5XiM=>

Meeting ID: 722 177 620

One tap mobile +16699006833,,722177620# US

Re: [ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

2020-04-03 Thread Woodruff, Robert J 
The possible value that I see would be:


  1.  There is a bug fix or enhancement that is contained to a vendor driver 
that the vendor wants to get to a customer without having to wait for the next 
distro release.
  2.  There is a bug fix in an older distro version and the vendor wants to 
provide their customer with an updated driver that fixes the bug. Even if the 
bug fix is available in a newer distro version, some customers do not want to 
upgrade to a newer distro version just to get a bug fix for one driver.
  3.  There are bug fixes or newer features in the latest user-space rdma-core 
or other user-space packages that someone wants.

The question is, do people in the EWG want to have a common OFED-lite package 
with all those updates or would they prefer to just deliver their own updated 
drivers to their customers which they can already do without any help for the 
EWG and OFED.

Woody

From: Davis, Arlin R 
Sent: Friday, April 03, 2020 2:57 PM
To: Vladimir Sokolovsky ; ewg@lists.openfabrics.org
Cc: Woodruff, Robert J 
Subject: RE: OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

Yes, updated drivers would be limited the in-kernel RDMA stack from the distro 
so we could not add new features, just provide bug fixing. I tend to agree, not 
much value, but I was asked to present the option to the working group. 
Clearly, we wouldn't move any faster than the distro, especially with their new 
commitment of a 6 month "predictable release cadence".

Maybe others can see value and can comment.


From: Vladimir Sokolovsky 
mailto:v...@dev.mellanox.co.il>>
Sent: Friday, April 03, 2020 12:02 PM
To: Davis, Arlin R mailto:arlin.r.da...@intel.com>>; 
ewg@lists.openfabrics.org
Cc: Woodruff, Robert J 
mailto:robert.j.woodr...@intel.com>>
Subject: Re: OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

On 04/03/2020 09:16 PM, Davis, Arlin R wrote:
Hello,

The recommendation from the OFA board is to move to a lite weight OFED 
packaging option. This new packaging would simply update the vendors drivers, 
rebased for distro's compat_rdma kernel sub-system. It would not replace the 
entire compat-rdma sub-system with latest upstream kernel versions. Not sure 
how we handle the out of tree builds for rdma_core in user-space, we may have 
to patch and rebuild entire package.

Would this be an acceptable packaging option for your company? Would there be 
any value without latest upstream compat-rdma stack?

We will discuss this on Monday, or you can simply reply to the EWG mailing list 
with your feedback.

Thanks,

Arlin

Hi Arlin,
Can you elaborate on the meaning of "simply update the vendors drivers, rebased 
for distro's compat_rdma kernel sub-system"? Isn't it already included in 
Distros?
In most cases vendor's driver cannot be updated without updating kernel's RDMA 
infrastructure which, in turn, will require other vendors drivers to be updated 
or disabled.
It is not clear which components OFED will include... For the user space there 
are only two options: use the in-box version (which means no new features) or 
replace the in-box version by the newer upstream version as of today.

Honestly, Distros are pretty up to date with the latest upstream changes, so 
that OFED release cycle is no shorter that most of the Distros release cycle. 
So, customers can get the latest updates just by upgrading to the new Distro 
version and this way they will continue to get support by Distros' vendors.
The added value of having community OFED was to provide support of the new 
features available upstream to older versions of Linux Distributions (when 
possible). But historically it did not really happened as most of the companies 
skipped on providing backports for their device drivers. So, it looses its 
value...

Other thoughts?

Regards,
Vladimir




Join Zoom Meeting
https://zoom.us/j/722177620

Meeting ID: 722 177 620

One tap mobile +16699006833,,722177620# US (San Jose) +16465588656,,722177620# 
US (New York)

Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New 
York) Meeting ID: 722 177 620 Find your local number: 
https://zoom.us/u/aesx25N6Us

Agenda:

*   OFED_5.x - discuss options for OFED lite, with distro kernel sub-system






___
ewg mailing list
ewg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ewg

Re: [ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

2020-04-03 Thread Davis, Arlin R 
Yes, updated drivers would be limited the in-kernel RDMA stack from the distro 
so we could not add new features, just provide bug fixing. I tend to agree, not 
much value, but I was asked to present the option to the working group. 
Clearly, we wouldn't move any faster than the distro, especially with their new 
commitment of a 6 month "predictable release cadence".

Maybe others can see value and can comment.

From: Vladimir Sokolovsky 
Sent: Friday, April 03, 2020 12:02 PM
To: Davis, Arlin R ; ewg@lists.openfabrics.org
Cc: Woodruff, Robert J 
Subject: Re: OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

On 04/03/2020 09:16 PM, Davis, Arlin R wrote:
Hello,

The recommendation from the OFA board is to move to a lite weight OFED 
packaging option. This new packaging would simply update the vendors drivers, 
rebased for distro's compat_rdma kernel sub-system. It would not replace the 
entire compat-rdma sub-system with latest upstream kernel versions. Not sure 
how we handle the out of tree builds for rdma_core in user-space, we may have 
to patch and rebuild entire package.

Would this be an acceptable packaging option for your company? Would there be 
any value without latest upstream compat-rdma stack?

We will discuss this on Monday, or you can simply reply to the EWG mailing list 
with your feedback.

Thanks,

Arlin

Hi Arlin,
Can you elaborate on the meaning of "simply update the vendors drivers, rebased 
for distro's compat_rdma kernel sub-system"? Isn't it already included in 
Distros?
In most cases vendor's driver cannot be updated without updating kernel's RDMA 
infrastructure which, in turn, will require other vendors drivers to be updated 
or disabled.
It is not clear which components OFED will include... For the user space there 
are only two options: use the in-box version (which means no new features) or 
replace the in-box version by the newer upstream version as of today.

Honestly, Distros are pretty up to date with the latest upstream changes, so 
that OFED release cycle is no shorter that most of the Distros release cycle. 
So, customers can get the latest updates just by upgrading to the new Distro 
version and this way they will continue to get support by Distros' vendors.
The added value of having community OFED was to provide support of the new 
features available upstream to older versions of Linux Distributions (when 
possible). But historically it did not really happened as most of the companies 
skipped on providing backports for their device drivers. So, it looses its 
value...

Other thoughts?

Regards,
Vladimir





Join Zoom Meeting
https://zoom.us/j/722177620

Meeting ID: 722 177 620

One tap mobile +16699006833,,722177620# US (San Jose) +16465588656,,722177620# 
US (New York)

Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New 
York) Meeting ID: 722 177 620 Find your local number: 
https://zoom.us/u/aesx25N6Us

Agenda:

* OFED_5.x - discuss options for OFED lite, with distro kernel 
sub-system






___
ewg mailing list
ewg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ewg

Re: [ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

2020-04-03 Thread Vladimir Sokolovsky 

On 04/03/2020 09:16 PM, Davis, Arlin R wrote:


Hello,

The recommendation from the OFA board is to move to a lite weight OFED 
packaging option. This new packaging would simply update the vendors 
drivers, rebased for distro’s compat_rdma kernel sub-system. It would 
not replace the entire compat-rdma sub-system with latest upstream 
kernel versions. Not sure how we handle the out of tree builds for 
rdma_core in user-space, we may have to patch and rebuild entire package.


Would this be an acceptable packaging option for your company? Would 
there be any value without latest upstream compat-rdma stack?


We will discuss this on Monday, or you can simply reply to the EWG 
mailing list with your feedback.


Thanks,

Arlin



Hi Arlin,
Can you elaborate on the meaning of "simply update the vendors drivers, 
rebased for distro’s compat_rdma kernel sub-system"? Isn't it already 
included in Distros?
In most cases vendor's driver cannot be updated without updating 
kernel's RDMA infrastructure which, in turn, will require other vendors 
drivers to be updated or disabled.
It is not clear which components OFED will include... For the user space 
there are only two options: use the in-box version (which means no new 
features) or replace the in-box version by the newer upstream version as 
of today.


Honestly, Distros are pretty up to date with the latest upstream 
changes, so that OFED release cycle is no shorter that most of the 
Distros release cycle. So, customers can get the latest updates just by 
upgrading to the new Distro version and this way they will continue to 
get support by Distros' vendors.
The added value of having community OFED was to provide support of the 
new features available upstream to older versions of Linux Distributions 
(when possible). But historically it did not really happened as most of 
the companies skipped on providing backports for their device drivers. 
So, it looses its value...


Other thoughts?

Regards,
Vladimir



Join Zoom Meeting
https://zoom.us/j/722177620 



Meeting ID: 722 177 620

One tap mobile +16699006833,,722177620# US (San Jose) 
+16465588656,,722177620# US (New York)


Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US 
(New York) Meeting ID: 722 177 620 Find your local number: 
https://zoom.us/u/aesx25N6Us 



*Agenda:*
·*OFED*_5.x – discuss options for OFED lite, with distro kernel sub-system



___
ewg mailing list
ewg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ewg

[ewg] OFA EWG Meeting: Monday, April 6th, 2020 - Agenda

2020-04-03 Thread Davis, Arlin R 
Hello,

The recommendation from the OFA board is to move to a lite weight OFED 
packaging option. This new packaging would simply update the vendors drivers, 
rebased for distro's compat_rdma kernel sub-system. It would not replace the 
entire compat-rdma sub-system with latest upstream kernel versions. Not sure 
how we handle the out of tree builds for rdma_core in user-space, we may have 
to patch and rebuild entire package.

Would this be an acceptable packaging option for your company? Would there be 
any value without latest upstream compat-rdma stack?

We will discuss this on Monday, or you can simply reply to the EWG mailing list 
with your feedback.

Thanks,

Arlin


Join Zoom Meeting
https://zoom.us/j/722177620

Meeting ID: 722 177 620

One tap mobile
+16699006833,,722177620# US (San Jose)
+16465588656,,722177620# US (New York)

Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
Meeting ID: 722 177 620
Find your local number: 
https://zoom.us/u/aesx25N6Us

Agenda:

* OFED_5.x - discuss options for OFED lite, with distro kernel 
sub-system




___
ewg mailing list
ewg@lists.openfabrics.org
https://lists.openfabrics.org/mailman/listinfo/ewg