On 12/13/2022 2:57 PM, Zhu, Lingshan wrote:
On 12/6/2022 4:25 PM, Jason Wang wrote:
On Fri, Nov 25, 2022 at 11:06 PM Zhu Lingshan
<lingshan.zhu@xxxxxxxxx> wrote:
This series implements features provisioning for ifcvf.
By applying this series, we allow userspace to create
a vDPA device with selected (management device supported)
feature bits and mask out others.
Examples:
a)The management device supported features:
$ vdpa mgmtdev show pci/0000:01:00.5
pci/0000:01:00.5:
supported_classes net
max_supported_vqs 9
dev_features MTU MAC MRG_RXBUF CTRL_VQ MQ ANY_LAYOUT VERSION_1
ACCESS_PLATFORM
b)Provision a vDPA device with all supported features:
$ vdpa dev add name vdpa0 mgmtdev pci/0000:01:00.5
$ vdpa/vdpa dev config show vdpa0
vdpa0: mac 00:e8:ca:11:be:05 link up link_announce false
max_vq_pairs 4 mtu 1500
negotiated_features MRG_RXBUF CTRL_VQ MQ VERSION_1 ACCESS_PLATFORM
c)Provision a vDPA device with a subset of the supported features:
$ vdpa dev add name vdpa0 mgmtdev pci/0000:01:00.5 device_features
0x300020020
$ vdpa dev config show vdpa0
mac 00:e8:ca:11:be:05 link up link_announce false
negotiated_features CTRL_VQ VERSION_1 ACCESS_PLATFORM
Please help review
Thanks
Changes from V1:
split original patch 1 ~ patch 3 to small patches that are less
than 100 lines,
True but.
so they can be applied to stalbe kernel(Jason)
It requires each patch fixes a real issue so I think those can not go
to -stable.
Btw, looking at git history what you want to decouple is basically
functional equivalent to a partial revert of this commit:
commit 378b2e956820ff5c082d05f42828badcfbabb614
Author: Zhu Lingshan <lingshan.zhu@xxxxxxxxx>
Date: Fri Jul 22 19:53:05 2022 +0800
vDPA/ifcvf: support userspace to query features and MQ of a
management device
Adapting to current netlink interfaces, this commit allows
userspace
to query feature bits and MQ capability of a management device.
Currently both the vDPA device and the management device are the
VF itself,
thus this ifcvf should initialize the virtio capabilities in
probe() before
setting up the struct vdpa_mgmt_dev.
Signed-off-by: Zhu Lingshan <lingshan.zhu@xxxxxxxxx>
Message-Id: <20220722115309.82746-3-lingshan.zhu@xxxxxxxxx>
Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
Before this commit. adapter was allocated/freed in device_add/del
which should be fine.
Can we go back to doing things that way?
Hi Jason
Thanks for your advice, my concern is, even revert this commit 378b2e95,
we still need to re-implement the feature "support userspace to query
features and MQ of a management device"
in stable kernel(still not a patch fix something but implement
something), or we remove a feature in the stable kernel.
And there may still need to split patches to meet the <100 lines
requirement
The reason why I place the adapter allocation in probe is that
currently the management device is the VF itself,
move it from dev_add to probe can lighten the organization of data
structures, it is not a good design anyway,
so this series tries to fix them as well.
Maybe not to to sable
Thanks
Hi Jason,
Ping,
shall I drop the "cc stable" tag and resend?
Maybe squash the patches because they are not going to stable tree?
Thanks
Thanks
Zhu Lingshan (12):
vDPA/ifcvf: decouple hw features manipulators from the adapter
vDPA/ifcvf: decouple config space ops from the adapter
vDPA/ifcvf: alloc the mgmt_dev before the adapter
vDPA/ifcvf: decouple vq IRQ releasers from the adapter
vDPA/ifcvf: decouple config IRQ releaser from the adapter
vDPA/ifcvf: decouple vq irq requester from the adapter
vDPA/ifcvf: decouple config/dev IRQ requester and vectors allocator
from the adapter
vDPA/ifcvf: ifcvf_request_irq works on ifcvf_hw
vDPA/ifcvf: manage ifcvf_hw in the mgmt_dev
vDPA/ifcvf: allocate the adapter in dev_add()
vDPA/ifcvf: retire ifcvf_private_to_vf
vDPA/ifcvf: implement features provisioning
drivers/vdpa/ifcvf/ifcvf_base.c | 32 ++-----
drivers/vdpa/ifcvf/ifcvf_base.h | 10 +-
drivers/vdpa/ifcvf/ifcvf_main.c | 162
+++++++++++++++-----------------
3 files changed, 91 insertions(+), 113 deletions(-)
--
2.31.1
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
