On Wed, Nov 9, 2022 at 5:06 PM Zhu, Lingshan <lingshan.zhu at intel.com> wrote:> > > > On 11/9/2022 4:59 PM, Jason Wang wrote: > > On Wed, Nov 9, 2022 at 4:14 PM Zhu, Lingshan <lingshan.zhu at intel.com> wrote: > >> > >> > >> On 11/9/2022 2:51 PM, Jason Wang wrote: > >>> On Mon, Nov 7, 2022 at 5:42 PM Zhu Lingshan <lingshan.zhu at intel.com> 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. > >>> I don't see a direct relationship between the first 3 and the last. > >>> Maybe you can state the reason why the restructure is a must for the > >>> feature provisioning. Otherwise, we'd better split the series. > >> When introducing features provisioning ability to ifcvf, there is a need > >> to re-create vDPA devices > >> on a VF with different feature bits. > > This seems a requirement even without feature provisioning? Device > > could be deleted from the management device anyhow. > Yes, we need this to delete and re-create a vDPA device.I wonder if we need something that works for -stable. AFAIK, we can move the vdpa_alloc_device() from probe() to dev_add() and it seems to work? Thanks> > We create vDPA device from a VF, so without features provisioning > requirements, > we don't need to re-create the vDPA device. But with features provisioning, > it is a must now. > > Thanks > > > > > > Thakns > > > >> When remove a vDPA device, the container of struct vdpa_device (here is > >> ifcvf_adapter) is free-ed in > >> dev_del() interface, so we need to allocate ifcvf_adapter in dev_add() > >> than in probe(). That's > >> why I have re-factored the adapter/mgmt_dev code. > >> > >> For re-factoring the irq related code and ifcvf_base, let them work on > >> struct ifcvf_hw, the > >> reason is that the adapter is allocated in dev_add(), if we want theses > >> functions to work > >> before dev_add(), like in probe, we need them work on ifcvf_hw than the > >> adapter. > >> > >> Thanks > >> Zhu Lingshan > >>> Thanks > >>> > >>>> Please help review > >>>> > >>>> Thanks > >>>> > >>>> Zhu Lingshan (4): > >>>> vDPA/ifcvf: ifcvf base layer interfaces work on struct ifcvf_hw > >>>> vDPA/ifcvf: IRQ interfaces work on ifcvf_hw > >>>> vDPA/ifcvf: allocate ifcvf_adapter in dev_add() > >>>> 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 | 156 +++++++++++++++----------------- > >>>> 3 files changed, 89 insertions(+), 109 deletions(-) > >>>> > >>>> -- > >>>> 2.31.1 > >>>> >
Zhu, Lingshan
2022-Nov-10 06:20 UTC
[PATCH 0/4] ifcvf/vDPA implement features provisioning
On 11/10/2022 11:49 AM, Jason Wang wrote:> On Wed, Nov 9, 2022 at 5:06 PM Zhu, Lingshan <lingshan.zhu at intel.com> wrote: >> >> >> On 11/9/2022 4:59 PM, Jason Wang wrote: >>> On Wed, Nov 9, 2022 at 4:14 PM Zhu, Lingshan <lingshan.zhu at intel.com> wrote: >>>> >>>> On 11/9/2022 2:51 PM, Jason Wang wrote: >>>>> On Mon, Nov 7, 2022 at 5:42 PM Zhu Lingshan <lingshan.zhu at intel.com> 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. >>>>> I don't see a direct relationship between the first 3 and the last. >>>>> Maybe you can state the reason why the restructure is a must for the >>>>> feature provisioning. Otherwise, we'd better split the series. >>>> When introducing features provisioning ability to ifcvf, there is a need >>>> to re-create vDPA devices >>>> on a VF with different feature bits. >>> This seems a requirement even without feature provisioning? Device >>> could be deleted from the management device anyhow. >> Yes, we need this to delete and re-create a vDPA device. > I wonder if we need something that works for -stable.I can add a fix tag, so these three patches could apply to stable> > AFAIK, we can move the vdpa_alloc_device() from probe() to dev_add() > and it seems to work?Yes and this is done in this series and that's why we need these refactoring code. By the way, do you have any comments to the patches? Thanks, Zhu Lingshan> > Thanks > >> We create vDPA device from a VF, so without features provisioning >> requirements, >> we don't need to re-create the vDPA device. But with features provisioning, >> it is a must now. >> >> Thanks >> >> >>> Thakns >>> >>>> When remove a vDPA device, the container of struct vdpa_device (here is >>>> ifcvf_adapter) is free-ed in >>>> dev_del() interface, so we need to allocate ifcvf_adapter in dev_add() >>>> than in probe(). That's >>>> why I have re-factored the adapter/mgmt_dev code. >>>> >>>> For re-factoring the irq related code and ifcvf_base, let them work on >>>> struct ifcvf_hw, the >>>> reason is that the adapter is allocated in dev_add(), if we want theses >>>> functions to work >>>> before dev_add(), like in probe, we need them work on ifcvf_hw than the >>>> adapter. >>>> >>>> Thanks >>>> Zhu Lingshan >>>>> Thanks >>>>> >>>>>> Please help review >>>>>> >>>>>> Thanks >>>>>> >>>>>> Zhu Lingshan (4): >>>>>> vDPA/ifcvf: ifcvf base layer interfaces work on struct ifcvf_hw >>>>>> vDPA/ifcvf: IRQ interfaces work on ifcvf_hw >>>>>> vDPA/ifcvf: allocate ifcvf_adapter in dev_add() >>>>>> 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 | 156 +++++++++++++++----------------- >>>>>> 3 files changed, 89 insertions(+), 109 deletions(-) >>>>>> >>>>>> -- >>>>>> 2.31.1 >>>>>>