Message-ID: <5d0439a6-8339-5bbd-c782-123a1aad71ed@intel.com>
Date:   Mon, 3 Apr 2023 16:36:56 -0500
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Jason Gunthorpe <jgg@...dia.com>, Jakub Kicinski <kuba@...nel.org>
CC:     Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
        <intel-wired-lan@...ts.osuosl.org>, <netdev@...r.kernel.org>,
        <shiraz.saleem@...el.com>, <emil.s.tantilov@...el.com>,
        <willemb@...gle.com>, <decot@...gle.com>, <joshua.a.hay@...el.com>,
        Christoph Hellwig <hch@....de>, <michael.orr@...el.com>,
        <anjali.singhai@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver

Posting on behalf of Michael Orr, Intel.
====

I am Michael Orr, from Intel
I am the Convener of IDPF TC at Oasis, and the Author of IDPF charter,
so Probably the right Person to answer this.

Due to tech issues in getting subscribed, I am asking my Colleague to
post this into the thread.

Bottom line: There is no issue in publishing this driver, and no
conflict with OASIS IDPF TC.

See point-by-point below

On 3/30/2023 1:29 PM, Jason Gunthorpe wrote:
> On Thu, Mar 30, 2023 at 10:25:05AM -0700, Jakub Kicinski wrote:
>> On Thu, 30 Mar 2023 09:03:09 -0300 Jason Gunthorpe wrote:
>>> On Wed, Mar 29, 2023 at 07:03:49AM -0700, Pavan Kumar Linga wrote:
>>>> This patch series introduces the Infrastructure Data Path Function (IDPF)
>>>> driver. It is used for both physical and virtual functions. Except for
>>>> some of the device operations the rest of the functionality is the same
>>>> for both PF and VF. IDPF uses virtchnl version2 opcodes and structures
>>>> defined in the virtchnl2 header file which helps the driver to learn
>>>> the capabilities and register offsets from the device Control Plane (CP)
>>>> instead of assuming the default values.
>>>
>>> Isn't IDPF currently being "standardized" at OASIS?

IDPF is indeed being Standardized at OASIS. Everyone is free (AND
INVITED!) to join the work.

>>>
>>> Has a standard been ratified? Isn't it rather premature to merge a
>>> driver for a standard that doesn't exist?

The Standard has not been ratified. Work has just started recently. When
IDPF TC members finish the work and vote to approve the result THAT
version will be the OASIS Standard IDPF specification, and will have a
reference driver to accompany it, likely labeled V1.0

>>>
>>> Publicly posting pre-ratification work is often against the IP
>>> policies of standards orgs, are you even legally OK to post this?

Publishing this driver does not go against any IP policy of OASIS or the
IDPF TC. There is no legal issue.

>>>
>>> Confused,
>>
>> And you called me politically motivated in the discussion about RDMA :|
>> Vendor posts a driver, nothing special as far as netdev is concerned.
> 
> The patches directly link to the OASIS working group, they need to
> explain WTF is going on here.

As explained in the Charter, Intel & Google are donating the current
Vendor driver & its spec to the IDPF TC to serve as a starting point for
an eventual vendor-agnostic Spec & Driver that will be the OASIS IDPF
standard set.

> 
> The published doucments they link to expressly say:
> 
>   This is version 0.9 of IDPF Specification, to serve as basis for IDPF
>   TC work. This is a work-in-progress document, and should not be used
>   for implementation as is.

Since I wrote this: This is intended to state that version 0.9
is NOT *the* OASIS IDPF TC driver, just a base to start working from.
We know the current version is not vendor independent and that it is
likely changes will be added by the IDPF TC.

> 
> Further OASIS has a legal IPR policy that basically means Intel needs
> to publicly justify that their Signed-off-by is consisent with the
> kernel rules of the DCO. ie that they have a legal right to submit
> this IP to the kernel.

OASIS does NOT have such a legal IPR policy. The only IPR policy that
applies to the IDPF TC members is the “Non-assert” IPR policy as stated
in the Charter.
Any IDPF TC member company is free to publish any vendor driver they
choose to. What they Publish is simply then their driver, and not an
implementation of the OASIS IDPF Standard.

IDPF Charter (And draft spec, and all other documents and mailings) are
here:
https://www.oasis-open.org/committees/documents.php?wg_abbrev=idpf&show_descriptions=yes

OASIS IPR Policies for TC’s are here: 
https://www.oasis-open.org/policies-guidelines/ipr/

> 
> It is frequent that people make IPR mistakes, it is something
> maintainers should be double-checking when they are aware of it.
> 
> Frankly, this stopped being a "vendor driver" as soon as they linked
> to OASIS documents.
> 
> More broadly we have seen good success in Linux with the
> standards-first model. NVMe for example will not merge "vendor
> extensions" and the like that are not in the published ratified
> standard. It gives more power to the standards bodies and encourages
> vendor collaboration.
> 
> It is up to netdev community, but it looks pretty wild to see patches
> link to a supposed multi-vendor OASIS standard, put the implementation
> under net/ethernet/intel/idpf/ and come before standard
> ratification.
> 
> It is a legitimate question if that is how netdev community wants to
> manage its standard backed drivers.
> 
> Jason

Powered by blists - more mailing lists