From: Leon Romanovsky <leon@kernel.org>
To: Parav Pandit <parav@nvidia.com>
Cc: "Ertman, David M" <david.m.ertman@intel.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH 1/6] Add ancillary bus support
Date: Fri, 2 Oct 2020 14:45:45 +0300 [thread overview]
Message-ID: <20201002114545.GB3094@unreal> (raw)
In-Reply-To: <BY5PR12MB432201FCEA970DA28AB06166DC310@BY5PR12MB4322.namprd12.prod.outlook.com>
On Fri, Oct 02, 2020 at 11:27:43AM +0000, Parav Pandit wrote:
>
>
> > From: Leon Romanovsky <leon@kernel.org>
> > Sent: Friday, October 2, 2020 4:44 PM
>
> [..]
> > > > ../../../devices/pci0000:00/0000:00:0b.0/mlx5_core.eth.2
> > > This gives you the ability to not load the netdevice and rdma device of a VF
> > and only load the vdpa device.
> > > These are real use case that users have asked for.
> > > In use case one, they are only interested in rdma device.
> > > In second use case only vdpa device.
> > > How shall one achieve that without spinning of the device for each class?
> >
> > Why will it be different if ancillary device is small PCI core?
> > If you want RDMA, you will use specific ancillary driver that connects to that
> > small PCI logic.
>
> I didn't follow, wwhat is PCI core and PCI logic in this context?
mlx5_core is PCI core/logic - ancillary device
mlx5_ib/mlx5_en/mlx5_vdpa - ancillary drivers
>
> Not sure if you understood the use case.
> Let me try again.
> Let say there are 4 VFs enabled.
> User would not like to create netdev for 3 VFs (0 to 2) ; user only wants rdma device for these VFs 0 to 2.
> User wants only vdpa device for 4th VF.
> User doesn't want to create rdma device and netdevice for the 4th VF.
> How one shall achieve this?
It depends on how N-to-1 bus will be implemented. For example, devlink
already allows to disable RoCE on specific function, nothing prohibits
to extend it to support other classes.
> It is easily achievable with current ancillary device instantiation per class proposal.
It is byproduct of 1-to-1 connection and not specific design decision.
>
> > Being nice to the users and provide clean abstraction are important goals too.
> Which part of this makes not_nice_to_users and what is not abstracted.
> I lost you.
Your use case perfectly presented not_nice_to_users thing. Users are
interested to work on functions (VF/PF/SF) and configure them without
need to dig into the sysfs directories to connect ancillary classes
and their indexes to the real functions.
Thanks
next prev parent reply other threads:[~2020-10-02 11:45 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 5:05 [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Dave Ertman
2020-10-01 5:05 ` [PATCH 1/6] Add ancillary bus support Dave Ertman
2020-10-01 8:32 ` Leon Romanovsky
2020-10-01 17:20 ` Ertman, David M
2020-10-01 17:40 ` Leon Romanovsky
2020-10-01 18:29 ` Parav Pandit
2020-10-01 19:32 ` Leon Romanovsky
2020-10-02 5:29 ` Parav Pandit
2020-10-02 6:20 ` Leon Romanovsky
2020-10-02 8:42 ` Parav Pandit
2020-10-02 11:13 ` Leon Romanovsky
2020-10-02 11:27 ` Parav Pandit
2020-10-02 11:45 ` Leon Romanovsky [this message]
2020-10-02 11:56 ` Parav Pandit
2020-10-01 5:05 ` [PATCH 2/6] ASoC: SOF: Introduce descriptors for SOF client Dave Ertman
2020-10-01 5:05 ` [PATCH 3/6] ASoC: SOF: Create client driver for IPC test Dave Ertman
2020-10-01 5:05 ` [PATCH 4/6] ASoC: SOF: ops: Add ops for client registration Dave Ertman
2020-10-01 5:05 ` [PATCH 5/6] ASoC: SOF: Intel: Define " Dave Ertman
2020-10-01 5:05 ` [PATCH 6/6] ASoC: SOF: debug: Remove IPC flood test support in SOF core Dave Ertman
2020-10-03 9:04 ` [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Leon Romanovsky
2020-10-03 9:10 ` Greg KH
2020-10-03 9:10 ` Greg KH
2020-10-03 9:24 ` Leon Romanovsky
2020-10-03 9:24 ` Leon Romanovsky
2020-10-03 9:32 ` Greg KH
2020-10-03 9:32 ` Greg KH
2020-10-05 1:20 ` Ertman, David M
-- strict thread matches above, loose matches on Subject: below --
2020-10-01 5:08 Dave Ertman
2020-10-01 5:08 ` [PATCH 1/6] Add ancillary bus support Dave Ertman
2020-09-30 22:50 [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Dave Ertman
2020-09-30 22:50 ` [PATCH 1/6] Add ancillary bus support Dave Ertman
2020-09-30 23:05 ` Jason Gunthorpe
2020-10-01 11:01 ` Greg KH
2020-10-01 11:46 ` Jason Gunthorpe
2020-10-01 11:54 ` Greg KH
2020-10-01 12:02 ` Jason Gunthorpe
2020-10-01 12:15 ` Greg KH
2020-10-01 18:26 ` Ertman, David M
2020-10-01 11:02 ` Greg KH
2020-10-01 16:30 ` Ertman, David M
2020-10-01 11:05 ` Greg KH
2020-10-01 11:58 ` Jason Gunthorpe
2020-10-01 12:14 ` Greg KH
2020-10-01 14:33 ` Jason Gunthorpe
2020-10-01 14:38 ` Greg KH
2020-10-01 16:06 ` Pierre-Louis Bossart
2020-10-01 17:42 ` Jason Gunthorpe
2020-10-01 14:39 ` Parav Pandit
2020-10-01 14:43 ` Greg KH
2020-10-01 13:27 ` Mark Brown
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=20201002114545.GB3094@unreal \
--to=leon@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=linux-rdma@vger.kernel.org \
--cc=parav@nvidia.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.