From: Parav Pandit <parav@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>, Saeed Mahameed <saeed@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Jiri Pirko <jiri@nvidia.com>,
"dledford@redhat.com" <dledford@redhat.com>,
Leon Romanovsky <leonro@nvidia.com>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [PATCH net-next 00/13] Add mlx5 subfunction support
Date: Fri, 20 Nov 2020 03:34:24 +0000 [thread overview]
Message-ID: <BY5PR12MB43226B04592F03E2D4E8A787DCFF0@BY5PR12MB4322.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20201119173521.204c4595@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Friday, November 20, 2020 7:05 AM
>
> On Wed, 18 Nov 2020 22:12:22 -0800 Saeed Mahameed wrote:
> > > Right, devices of other subsystems are fine, I don't care.
> >
> > But a netdev will be loaded on SF automatically just through the
> > current driver design and modularity, since SF == VF and our netdev is
> > abstract and doesn't know if it runs on a PF/VF/SF .. we literally
> > have to add code to not load a netdev on a SF. why ? :/
>
> A netdev is fine, but the examples so far don't make it clear (to me) if it's
> expected/supported to spawn _multiple_ netdevs from a single "vdpa
> parentdev".
We do not create Netdev from vdpa parentdev.
From vdpa parentdev, only vdpa device(s) are created which is 'struct device' residing in /sys/bus/vdpa/<device>.
Currently such vdpa device is already created on mlx5_vpa.ko driver load, however user has no way to inspect, stats, get/set features of this device, hence the vdpa tool.
next prev parent reply other threads:[~2020-11-20 3:34 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 19:24 [PATCH net-next 00/13] Add mlx5 subfunction support 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
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 [this message]
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=BY5PR12MB43226B04592F03E2D4E8A787DCFF0@BY5PR12MB4322.namprd12.prod.outlook.com \
--to=parav@nvidia.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=saeed@kernel.org \
/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.