All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: willemb@google.com, pabeni@redhat.com, leon@kernel.org,
	simon.horman@corigine.com, jesse.brandeburg@intel.com,
	edumazet@google.com, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, kuba@kernel.org,
	anthony.l.nguyen@intel.com, decot@google.com,
	davem@davemloft.net, shannon.nelson@amd.com
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver
Date: Thu, 18 May 2023 13:10:29 -0400	[thread overview]
Message-ID: <20230518130452-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <6a900cd7-470a-3611-c88a-9f901c56c97f@intel.com>

On Thu, May 18, 2023 at 09:19:31AM -0700, Samudrala, Sridhar wrote:
> 
> 
> On 5/11/2023 11:34 PM, Michael S. Tsirkin wrote:
> > On Mon, May 08, 2023 at 12:43:11PM -0700, Emil Tantilov wrote:
> > > This patch series introduces the Intel 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.
> > 
> > So, is this for merge in the next cycle?  Should this be an RFC rather?
> > It seems unlikely that the IDPF specification will be finalized by that
> > time - how are you going to handle any specification changes?
> 
> Yes. we would like this driver to be merged in the next cycle(6.5).
> Based on the community feedback on v1 version of the driver, we removed all
> references to OASIS standard and at this time this is an intel vendor
> driver.
> 
> Links to v1 and v2 discussion threads
> https://lore.kernel.org/netdev/20230329140404.1647925-1-pavan.kumar.linga@intel.com/
> https://lore.kernel.org/netdev/20230411011354.2619359-1-pavan.kumar.linga@intel.com/
> 
> The v1->v2 change log reflects this update.
> v1 --> v2: link [1]
>  * removed the OASIS reference in the commit message to make it clear
>    that this is an Intel vendor specific driver

Yes this makes sense.


> Any IDPF specification updates would be handled as part of the changes that
> would be required to make this a common standards driver.


So my question is, would it make sense to update Kconfig and module name
to be "ipu" or if you prefer "intel-idpf" to make it clear this is
currently an Intel vendor specific driver?  And then when you make it a
common standards driver rename it to idpf?  The point being to help make
sure users are not confused about whether they got a driver with
or without IDPF updates. It's not critical I guess but seems like a good
idea. WDYT?

-- 
MST

_______________________________________________
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: "Michael S. Tsirkin" <mst@redhat.com>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: Emil Tantilov <emil.s.tantilov@intel.com>,
	intel-wired-lan@lists.osuosl.org, shannon.nelson@amd.com,
	simon.horman@corigine.com, leon@kernel.org, decot@google.com,
	willemb@google.com, jesse.brandeburg@intel.com,
	anthony.l.nguyen@intel.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver
Date: Thu, 18 May 2023 13:10:29 -0400	[thread overview]
Message-ID: <20230518130452-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <6a900cd7-470a-3611-c88a-9f901c56c97f@intel.com>

On Thu, May 18, 2023 at 09:19:31AM -0700, Samudrala, Sridhar wrote:
> 
> 
> On 5/11/2023 11:34 PM, Michael S. Tsirkin wrote:
> > On Mon, May 08, 2023 at 12:43:11PM -0700, Emil Tantilov wrote:
> > > This patch series introduces the Intel 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.
> > 
> > So, is this for merge in the next cycle?  Should this be an RFC rather?
> > It seems unlikely that the IDPF specification will be finalized by that
> > time - how are you going to handle any specification changes?
> 
> Yes. we would like this driver to be merged in the next cycle(6.5).
> Based on the community feedback on v1 version of the driver, we removed all
> references to OASIS standard and at this time this is an intel vendor
> driver.
> 
> Links to v1 and v2 discussion threads
> https://lore.kernel.org/netdev/20230329140404.1647925-1-pavan.kumar.linga@intel.com/
> https://lore.kernel.org/netdev/20230411011354.2619359-1-pavan.kumar.linga@intel.com/
> 
> The v1->v2 change log reflects this update.
> v1 --> v2: link [1]
>  * removed the OASIS reference in the commit message to make it clear
>    that this is an Intel vendor specific driver

Yes this makes sense.


> Any IDPF specification updates would be handled as part of the changes that
> would be required to make this a common standards driver.


So my question is, would it make sense to update Kconfig and module name
to be "ipu" or if you prefer "intel-idpf" to make it clear this is
currently an Intel vendor specific driver?  And then when you make it a
common standards driver rename it to idpf?  The point being to help make
sure users are not confused about whether they got a driver with
or without IDPF updates. It's not critical I guess but seems like a good
idea. WDYT?

-- 
MST


  reply	other threads:[~2023-05-18 17:10 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08 19:43 [Intel-wired-lan] [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver Emil Tantilov
2023-05-08 19:43 ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 01/15] virtchnl: add virtchnl version 2 ops Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 02/15] idpf: add module register and probe functionality Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-09  2:11   ` [Intel-wired-lan] " Yunsheng Lin
2023-05-09  2:11     ` Yunsheng Lin
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 03/15] idpf: add controlq init and reset checks Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 04/15] idpf: add core init and interrupt request Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 05/15] idpf: add create vport and netdev configuration Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 06/15] idpf: continue expanding init task Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 07/15] idpf: configure resources for TX queues Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 08/15] idpf: configure resources for RX queues Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 09/15] idpf: initialize interrupts and enable vport Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 10/15] idpf: add splitq start_xmit Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 11/15] idpf: add TX splitq napi poll support Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 12/15] idpf: add RX " Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 13/15] idpf: add singleq start_xmit and napi poll Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 14/15] idpf: add ethtool callbacks Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-08 19:43 ` [Intel-wired-lan] [PATCH iwl-next v4 15/15] idpf: configure SRIOV and add other ndo_ops Emil Tantilov
2023-05-08 19:43   ` Emil Tantilov
2023-05-09  4:46   ` [Intel-wired-lan] " Bagas Sanjaya
2023-05-09  4:46     ` Bagas Sanjaya
2023-05-12 13:48     ` [Intel-wired-lan] " Tantilov, Emil S
2023-05-12 13:48       ` Tantilov, Emil S
2023-05-12  6:34 ` [Intel-wired-lan] [PATCH iwl-next v4 00/15] Introduce Intel IDPF driver Michael S. Tsirkin
2023-05-12  6:34   ` Michael S. Tsirkin
2023-05-18 16:19   ` [Intel-wired-lan] " Samudrala, Sridhar
2023-05-18 16:19     ` Samudrala, Sridhar
2023-05-18 17:10     ` Michael S. Tsirkin [this message]
2023-05-18 17:10       ` Michael S. Tsirkin
2023-05-18 23:26       ` [Intel-wired-lan] " Samudrala, Sridhar
2023-05-18 23:26         ` Samudrala, Sridhar
2023-05-19  5:49         ` [Intel-wired-lan] " Michael S. Tsirkin
2023-05-19  5:49           ` Michael S. Tsirkin
2023-05-19 17:36           ` [Intel-wired-lan] " Samudrala, Sridhar
2023-05-19 17:36             ` Samudrala, Sridhar
2023-05-19 18:22             ` [Intel-wired-lan] " Andrew Lunn
2023-05-19 18:22               ` Andrew Lunn
2023-05-19 18:42               ` [Intel-wired-lan] " Willem de Bruijn
2023-05-19 18:42                 ` Willem de Bruijn
2023-05-21  9:21             ` [Intel-wired-lan] " Michael S. Tsirkin
2023-05-21  9:21               ` Michael S. Tsirkin
2023-05-22  2:54               ` [Intel-wired-lan] " Samudrala, Sridhar
2023-05-22  2:54                 ` Samudrala, Sridhar
2023-05-22 20:08               ` [Intel-wired-lan] " Singhai, Anjali
2023-05-22 20:08                 ` Singhai, Anjali
2023-05-22 20:37                 ` [Intel-wired-lan] " Andrew Lunn
2023-05-22 20:37                   ` Andrew Lunn
2023-05-19 16:17         ` [Intel-wired-lan] " Shannon Nelson
2023-05-19 16:17           ` Shannon Nelson
2023-05-19 17:12           ` [Intel-wired-lan] " Willem de Bruijn
2023-05-19 17:12             ` Willem de Bruijn
2023-05-22 19:04             ` [Intel-wired-lan] " Michael S. Tsirkin
2023-05-22 19:04               ` Michael S. Tsirkin

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=20230518130452-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=decot@google.com \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shannon.nelson@amd.com \
    --cc=simon.horman@corigine.com \
    --cc=sridhar.samudrala@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.