From: Jakub Kicinski <kuba@kernel.org>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: willemb@google.com, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org,
Phani Burra <phani.r.burra@intel.com>,
decot@google.com, shiraz.saleem@intel.com
Subject: Re: [Intel-wired-lan] [PATCH net-next 01/15] virtchnl: add virtchnl version 2 ops
Date: Mon, 3 Apr 2023 16:30:25 -0700 [thread overview]
Message-ID: <20230403163025.5f40a87c@kernel.org> (raw)
In-Reply-To: <eb945338-915a-64cd-52c5-3d818ba45667@amd.com>
On Mon, 3 Apr 2023 15:54:33 -0700 Shannon Nelson wrote:
> > The noise about this driver being "a standard" is quite confusing.
> >
> > Are you considering implementing any of it?
> >
> > I haven't heard of anyone who is yet, so I thought all this talk of
> > a standard is pretty empty from the technical perspective :(
>
> Just that they seem to be pushing it to become a standard through OASIS,
> as they infer by pointing to their OASIS docs in this patch, and I was
> under the (mistaken?) impression that this would be the One Driver for
> any device that implemented the HW/FW interface, kinda like virtio. If
> that's true, then why would the driver live under the Intel directory?
Fair point. But standards are generally defined by getting interested
parties together and agreeing. Not by a vendor taking a barely deployed
implementation to some unfamiliar forum and claiming it's a standard.
I think it should be 100% clear that to netdev this is just another
(yet another?) Ethernet driver from Intel, nothing more.
Maybe I should say this more strongly, given certain rumors... Here:
Reviewing / merging of this driver into the tree should not be
interpreted as netdev recognizing or supporting idpf as any sort
of a standard. This is our position until the driver is in fact
adopted by other vendors. Attempts to misrepresent our position
and any claims that merging of this *vendor driver* constitutes
adoption of the standard will result in removal of the driver.
Is that helpful? There seems to be a lot of FUD around IDPF.
I'd prefer to stay out of it.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: Pavan Kumar Linga <pavan.kumar.linga@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
shiraz.saleem@intel.com, emil.s.tantilov@intel.com,
willemb@google.com, decot@google.com, joshua.a.hay@intel.com,
sridhar.samudrala@intel.com, Alan Brady <alan.brady@intel.com>,
Madhu Chittim <madhu.chittim@intel.com>,
Phani Burra <phani.r.burra@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 01/15] virtchnl: add virtchnl version 2 ops
Date: Mon, 3 Apr 2023 16:30:25 -0700 [thread overview]
Message-ID: <20230403163025.5f40a87c@kernel.org> (raw)
In-Reply-To: <eb945338-915a-64cd-52c5-3d818ba45667@amd.com>
On Mon, 3 Apr 2023 15:54:33 -0700 Shannon Nelson wrote:
> > The noise about this driver being "a standard" is quite confusing.
> >
> > Are you considering implementing any of it?
> >
> > I haven't heard of anyone who is yet, so I thought all this talk of
> > a standard is pretty empty from the technical perspective :(
>
> Just that they seem to be pushing it to become a standard through OASIS,
> as they infer by pointing to their OASIS docs in this patch, and I was
> under the (mistaken?) impression that this would be the One Driver for
> any device that implemented the HW/FW interface, kinda like virtio. If
> that's true, then why would the driver live under the Intel directory?
Fair point. But standards are generally defined by getting interested
parties together and agreeing. Not by a vendor taking a barely deployed
implementation to some unfamiliar forum and claiming it's a standard.
I think it should be 100% clear that to netdev this is just another
(yet another?) Ethernet driver from Intel, nothing more.
Maybe I should say this more strongly, given certain rumors... Here:
Reviewing / merging of this driver into the tree should not be
interpreted as netdev recognizing or supporting idpf as any sort
of a standard. This is our position until the driver is in fact
adopted by other vendors. Attempts to misrepresent our position
and any claims that merging of this *vendor driver* constitutes
adoption of the standard will result in removal of the driver.
Is that helpful? There seems to be a lot of FUD around IDPF.
I'd prefer to stay out of it.
next prev parent reply other threads:[~2023-04-03 23:30 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 14:03 [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 01/15] virtchnl: add virtchnl version 2 ops Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-31 15:25 ` Simon Horman
2023-03-31 15:25 ` Simon Horman
2023-04-03 22:01 ` Shannon Nelson
2023-04-03 22:01 ` Shannon Nelson
2023-04-03 22:20 ` Jakub Kicinski
2023-04-03 22:20 ` Jakub Kicinski
2023-04-03 22:54 ` Shannon Nelson
2023-04-03 22:54 ` Shannon Nelson
2023-04-03 23:30 ` Jakub Kicinski [this message]
2023-04-03 23:30 ` Jakub Kicinski
2023-04-04 7:59 ` Orr, Michael
2023-04-04 7:59 ` Orr, Michael
2023-04-04 16:25 ` Shannon Nelson
2023-04-04 16:25 ` Shannon Nelson
2023-04-04 19:41 ` Orr, Michael
2023-04-04 19:41 ` Orr, Michael
2023-04-10 20:27 ` Linga, Pavan Kumar
2023-04-10 20:27 ` Linga, Pavan Kumar
2023-04-10 22:12 ` Shannon Nelson
2023-04-10 22:12 ` Shannon Nelson
2023-04-12 16:58 ` Tantilov, Emil S
2023-04-12 16:58 ` Tantilov, Emil S
2023-04-12 21:36 ` Shannon Nelson
2023-04-12 21:36 ` Shannon Nelson
2023-04-13 18:54 ` Tantilov, Emil S
2023-04-13 18:54 ` Tantilov, Emil S
2023-04-13 21:03 ` Shannon Nelson
2023-04-13 21:03 ` Shannon Nelson
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 02/15] idpf: add module register and probe functionality Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 03/15] idpf: add controlq init and reset checks Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 04/15] idpf: add core init and interrupt request Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-31 15:39 ` Simon Horman
2023-03-31 15:39 ` Simon Horman
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 05/15] idpf: add create vport and netdev configuration Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-31 15:46 ` Simon Horman
2023-03-31 15:46 ` Simon Horman
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 06/15] idpf: continue expanding init task Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-31 15:47 ` Simon Horman
2023-03-31 15:47 ` Simon Horman
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 07/15] idpf: configure resources for TX queues Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-30 5:06 ` kernel test robot
2023-03-30 8:40 ` kernel test robot
2023-03-31 15:49 ` Simon Horman
2023-03-31 15:49 ` Simon Horman
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 08/15] idpf: configure resources for RX queues Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 09/15] idpf: initialize interrupts and enable vport Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-31 15:59 ` Simon Horman
2023-03-31 15:59 ` Simon Horman
2023-04-04 19:36 ` Linga, Pavan Kumar
2023-04-04 19:36 ` Linga, Pavan Kumar
2023-04-05 10:07 ` Simon Horman
2023-04-05 10:07 ` Simon Horman
2023-03-29 14:03 ` [Intel-wired-lan] [PATCH net-next 10/15] idpf: add splitq start_xmit Pavan Kumar Linga
2023-03-29 14:03 ` Pavan Kumar Linga
2023-03-29 14:04 ` [Intel-wired-lan] [PATCH net-next 11/15] idpf: add TX splitq napi poll support Pavan Kumar Linga
2023-03-29 14:04 ` Pavan Kumar Linga
2023-03-29 14:04 ` [Intel-wired-lan] [PATCH net-next 12/15] idpf: add RX " Pavan Kumar Linga
2023-03-29 14:04 ` Pavan Kumar Linga
2023-03-30 16:23 ` Maciej Fijalkowski
2023-03-30 16:23 ` Maciej Fijalkowski
2023-04-05 0:51 ` Tantilov, Emil S
2023-04-05 0:51 ` Tantilov, Emil S
2023-03-29 14:04 ` [Intel-wired-lan] [PATCH net-next 13/15] idpf: add singleq start_xmit and napi poll Pavan Kumar Linga
2023-03-29 14:04 ` Pavan Kumar Linga
2023-03-29 14:04 ` [Intel-wired-lan] [PATCH net-next 14/15] idpf: add ethtool callbacks Pavan Kumar Linga
2023-03-29 14:04 ` Pavan Kumar Linga
2023-03-29 15:33 ` Andrew Lunn
2023-03-29 15:33 ` Andrew Lunn
2023-03-30 22:05 ` Linga, Pavan Kumar
2023-03-30 22:05 ` Linga, Pavan Kumar
2023-03-29 14:04 ` [Intel-wired-lan] [PATCH net-next 15/15] idpf: configure SRIOV and add other ndo_ops Pavan Kumar Linga
2023-03-29 14:04 ` Pavan Kumar Linga
2023-03-29 15:41 ` [Intel-wired-lan] [PATCH net-next 00/15] Introduce IDPF driver Paul Menzel
2023-03-29 15:41 ` Paul Menzel
2023-03-30 21:31 ` Linga, Pavan Kumar
2023-03-30 21:31 ` Linga, Pavan Kumar
2023-03-29 17:31 ` Willem de Bruijn
2023-03-29 17:31 ` Willem de Bruijn
2023-03-30 12:03 ` Jason Gunthorpe
2023-03-30 12:03 ` Jason Gunthorpe
2023-03-30 17:25 ` Jakub Kicinski
2023-03-30 17:25 ` Jakub Kicinski
2023-03-30 18:29 ` Jason Gunthorpe
2023-03-30 18:29 ` Jason Gunthorpe
2023-04-03 21:36 ` Samudrala, Sridhar
2023-04-03 21:36 ` Samudrala, Sridhar
2023-04-04 16:42 ` Jason Gunthorpe
2023-04-04 16:42 ` Jason Gunthorpe
2023-04-04 19:19 ` Orr, Michael
2023-04-04 19:19 ` Orr, Michael
2023-04-04 23:35 ` Jason Gunthorpe
2023-04-04 23:35 ` Jason Gunthorpe
2023-04-07 4:39 ` Christoph Hellwig
2023-04-07 4:39 ` Christoph Hellwig
2023-04-07 18:01 ` Shannon Nelson
2023-04-07 18:01 ` Shannon Nelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230403163025.5f40a87c@kernel.org \
--to=kuba@kernel.org \
--cc=decot@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=netdev@vger.kernel.org \
--cc=phani.r.burra@intel.com \
--cc=shannon.nelson@amd.com \
--cc=shiraz.saleem@intel.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.