Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver

From: Jason Gunthorpe <jgg@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: willemb@google.com, netdev@vger.kernel.org,
	Pavan Kumar Linga <pavan.kumar.linga@intel.com>,
	intel-wired-lan@lists.osuosl.org, decot@google.com,
	shiraz.saleem@intel.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver
Date: Thu, 30 Mar 2023 15:29:39 -0300	[thread overview]
Message-ID: <ZCXVE9CuaMbY+Cdl@nvidia.com> (raw)
In-Reply-To: <20230330102505.6d3b88da@kernel.org>

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?
> > 
> > Has a standard been ratified? Isn't it rather premature to merge a
> > driver for a standard that doesn't exist?
> > 
> > Publicly posting pre-ratification work is often against the IP
> > policies of standards orgs, are you even legally OK to post this?
> > 
> > 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.

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.

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.

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
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan