From: Alexander Duyck <firstname.lastname@example.org> To: Jakub Kicinski <email@example.com> Cc: David Ahern <firstname.lastname@example.org>, Jason Gunthorpe <email@example.com>, Parav Pandit <firstname.lastname@example.org>, Saeed Mahameed <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Jiri Pirko <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Leon Romanovsky <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH net-next 00/13] Add mlx5 subfunction support Date: Fri, 20 Nov 2020 09:58:16 -0800 [thread overview] Message-ID: <CAKgT0Uf4i9hrq6Z4dx03sv_ubVpZwKm5Tiz+-UwJp38cTyZgfirstname.lastname@example.org> (raw) In-Reply-To: <20201119172930.11ab9e68@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> On Thu, Nov 19, 2020 at 5:29 PM Jakub Kicinski <email@example.com> wrote: > > On Wed, 18 Nov 2020 21:35:29 -0700 David Ahern wrote: > > On 11/18/20 7:14 PM, Jakub Kicinski wrote: > > > On Tue, 17 Nov 2020 14:49:54 -0400 Jason Gunthorpe wrote: > > >> On Tue, Nov 17, 2020 at 09:11:20AM -0800, Jakub Kicinski wrote: > > >> > > >>>> Just to refresh all our memory, we discussed and settled on the flow > > >>>> in ; RFC  followed this discussion. > > >>>> > > >>>> vdpa tool of  can add one or more vdpa device(s) on top of already > > >>>> spawned PF, VF, SF device. > > >>> > > >>> Nack for the networking part of that. It'd basically be VMDq. > > >> > > >> What are you NAK'ing? > > > > > > Spawning multiple netdevs from one device by slicing up its queues. > > > > Why do you object to that? Slicing up h/w resources for virtual what > > ever has been common practice for a long time. > > My memory of the VMDq debate is hazy, let me rope in Alex into this. > I believe the argument was that we should offload software constructs, > not create HW-specific APIs which depend on HW availability and > implementation. So the path we took was offloading macvlan. I think it somewhat depends on the type of interface we are talking about. What we were wanting to avoid was drivers spawning their own unique VMDq netdevs and each having a different way of doing it. The approach Intel went with was to use a MACVLAN offload to approach it. Although I would imagine many would argue the approach is somewhat dated and limiting since you cannot do many offloads on a MACVLAN interface. With the VDPA case I believe there is a set of predefined virtio devices that are being emulated and presented so it isn't as if they are creating a totally new interface for this. What I would be interested in seeing is if there are any other vendors that have reviewed this and sign off on this approach. What we don't want to see is Nivida/Mellanox do this one way, then Broadcom or Intel come along later and have yet another way of doing this. We need an interface and feature set that will work for everyone in terms of how this will look going forward.
next prev parent reply other threads:[~2020-11-20 17:58 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-12 19:24 Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 01/13] devlink: Prepare code to fill multiple port function attributes Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 02/13] devlink: Introduce PCI SF port flavour and port attribute Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 03/13] devlink: Support add and delete devlink port Parav Pandit 2020-11-18 16:21 ` David Ahern 2020-11-18 17:02 ` Parav Pandit 2020-11-18 18:03 ` David Ahern 2020-11-18 18:38 ` Jason Gunthorpe 2020-11-18 19:36 ` David Ahern 2020-11-18 20:42 ` Jason Gunthorpe 2020-11-18 19:22 ` Parav Pandit 2020-11-19 0:41 ` Jacob Keller 2020-11-19 1:17 ` David Ahern 2020-11-19 1:56 ` Samudrala, Sridhar 2020-11-19 0:52 ` Jacob Keller 2020-11-12 19:24 ` [PATCH net-next 04/13] devlink: Support get and set state of port function Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 05/13] devlink: Avoid global devlink mutex, use per instance reload lock Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 06/13] devlink: Introduce devlink refcount to reduce scope of global devlink_mutex Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 07/13] net/mlx5: SF, Add auxiliary device support Parav Pandit 2020-12-07 2:48 ` David Ahern 2020-12-07 4:53 ` Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 08/13] net/mlx5: SF, Add auxiliary device driver Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 09/13] net/mlx5: E-switch, Prepare eswitch to handle SF vport Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 10/13] net/mlx5: E-switch, Add eswitch helpers for " Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 11/13] net/mlx5: SF, Add SF configuration hardware commands Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 12/13] net/mlx5: SF, Add port add delete functionality Parav Pandit 2020-11-12 19:24 ` [PATCH net-next 13/13] net/mlx5: SF, Port function state change support Parav Pandit 2020-11-16 22:52 ` [PATCH net-next 00/13] Add mlx5 subfunction support Jakub Kicinski 2020-11-17 0:06 ` Saeed Mahameed 2020-11-17 1:58 ` Jakub Kicinski 2020-11-17 4:08 ` Parav Pandit 2020-11-17 17:11 ` Jakub Kicinski 2020-11-17 18:49 ` Jason Gunthorpe 2020-11-19 2:14 ` Jakub Kicinski 2020-11-19 4:35 ` David Ahern 2020-11-19 5:57 ` Saeed Mahameed 2020-11-20 1:31 ` Jakub Kicinski 2020-11-25 5:33 ` David Ahern 2020-11-25 6:00 ` Parav Pandit 2020-11-25 14:37 ` David Ahern 2020-11-20 1:29 ` Jakub Kicinski 2020-11-20 17:58 ` Alexander Duyck [this message] 2020-11-20 19:04 ` Samudrala, Sridhar 2020-11-23 21:51 ` Saeed Mahameed 2020-11-24 7:01 ` Jason Wang 2020-11-24 7:05 ` Jason Wang 2020-11-19 6:12 ` Saeed Mahameed 2020-11-19 8:25 ` Parav Pandit 2020-11-20 1:35 ` Jakub Kicinski 2020-11-20 3:34 ` Parav Pandit 2020-11-17 18:50 ` Parav Pandit 2020-11-19 2:23 ` Jakub Kicinski 2020-11-19 6:22 ` Saeed Mahameed 2020-11-19 14:00 ` Jason Gunthorpe 2020-11-20 3:35 ` Jakub Kicinski 2020-11-20 3:50 ` Parav Pandit 2020-11-20 16:16 ` Jason Gunthorpe
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=CAKgT0Uf4i9hrq6Z4dx03sv_ubVpZwKm5Tiz+-UwJp38cTyZgfirstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH net-next 00/13] Add mlx5 subfunction support' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).