[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc39973a-3f57-87d0-ff46-15a09e9b5f58@amd.com>
Date: Sat, 1 Apr 2023 13:15:03 -0700
From: Shannon Nelson <shannon.nelson@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: brett.creeley@....com, davem@...emloft.net, netdev@...r.kernel.org,
kuba@...nel.org, drivers@...sando.io, jiri@...nulli.us
Subject: Re: [PATCH v8 net-next 10/14] pds_core: add auxiliary_bus devices
On 4/1/23 11:27 AM, Leon Romanovsky wrote:
>
> On Thu, Mar 30, 2023 at 04:46:24PM -0700, Shannon Nelson wrote:
>> An auxiliary_bus device is created for each vDPA type VF at VF probe
>> and destroyed at VF remove. The VFs are always removed on PF remove, so
>> there should be no issues with VFs trying to access missing PF structures.
>>
>> Signed-off-by: Shannon Nelson <shannon.nelson@....com>
>> ---
>> drivers/net/ethernet/amd/pds_core/Makefile | 1 +
>> drivers/net/ethernet/amd/pds_core/auxbus.c | 142 +++++++++++++++++++++
>> drivers/net/ethernet/amd/pds_core/core.h | 6 +
>> drivers/net/ethernet/amd/pds_core/main.c | 36 +++++-
>> include/linux/pds/pds_auxbus.h | 16 +++
>> include/linux/pds/pds_common.h | 1 +
>> 6 files changed, 200 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/net/ethernet/amd/pds_core/auxbus.c
>> create mode 100644 include/linux/pds/pds_auxbus.h
>
> I feel that this auxbus usage is still not correct.
>
> The idea of auxiliary devices is to partition physical device (for
> example PCI device) to different sub-devices, where every sub-device
> belongs to different sub-system. It is not intended to create per-VF
> devices.
>
> In your case, you should create XXX vDPA auxiliary devices which are
> connected in one-to-one scheme to their PCI VF counterpart.
I don't understand - first I read
"It is not intended to create per-VF devices"
and then
"you should create XXX vDPA auxiliary devices which are
connected in one-to-one scheme to their PCI VF counterpart."
These seem at first to be directly contradictory statements, so maybe
I'm missing some nuance.
We have a PF device that has an adminq, VF devices that don't have an
adminq, and the adminq is needed for some basic setup before the rest of
the vDPA driver can use the VF. To access the PF's adminq we set up an
auxiliary device per feature in each VF - but currently only offer one
feature (vDPA) and no sub-devices yet. We're trying to plan for the future.
Is it that we only have one feature per VF so far is what is causing the
discomfort?
sln
Powered by blists - more mailing lists