[dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support

[Stillwell Jr, Paul M]

See my responses inline.

Paul

> -----Original Message-----
> From: Zhang, Qi Z <qi.z.zhang at intel.com>
> Sent: Saturday, March 14, 2020 6:50 PM
> To: Stillwell Jr, Paul M <paul.m.stillwell.jr at intel.com>; Wang, Haiyue
> <haiyue.wang at intel.com>; dev at dpdk.org; Ye, Xiaolong
> <xiaolong.ye at intel.com>; Yang, Qiming <qiming.yang at intel.com>; Xing,
> Beilei <beilei.xing at intel.com>
> Cc: Zhao1, Wei <wei.zhao1 at intel.com>; Wang, Haiyue
> <haiyue.wang at intel.com>; Liang, Cunming <cunming.liang at intel.com>; Wu,
> Jingjing <jingjing.wu at intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support
> 
> Hi Paul:
> 
> > -----Original Message-----
> > From: Stillwell Jr, Paul M <paul.m.stillwell.jr at intel.com>
> > Sent: Saturday, March 14, 2020 12:19 AM
> > To: Wang, Haiyue <haiyue.wang at intel.com>; dev at dpdk.org; Ye, Xiaolong
> > <xiaolong.ye at intel.com>; Zhang, Qi Z <qi.z.zhang at intel.com>; Yang,
> > Qiming <qiming.yang at intel.com>; Xing, Beilei <beilei.xing at intel.com>
> > Cc: Zhao1, Wei <wei.zhao1 at intel.com>; Wang, Haiyue
> > <haiyue.wang at intel.com>
> > Subject: RE: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support
> >
> > I'm confused. Shouldn't the DCF be a separate driver since it is a VF,
> > not part of a PF? You are starting to combine PF/VF code and I'm not
> > sure if that is the correct way to go.
> 
> From DPDK's view, DCF is NOT a VF driver, actually it behaves like a PF driver
> with control path only and it share most exist PF driver's API implementation

It *is* a VF. The only way this will work is if the VF has the trust flag set and then it can become the DCF. You can't set the trust flag on a PF I don't think. That's the only way this will work because the kernel driver code has checks on the admin queue messages to see if the message is from a VF. If it's not a message from a specific VF, then the message will get rejected.

> , That's why we combined it with exist PF driver, so when the module
> driver/net/ice is compiled into a library, it can be probed as a PF driver or DCF
> base on device ID at runtime.
> And the is not special in DPDK, for example, the module in driver/net/i40e
> can be probed as i40e pf driver or i40e vf driver.
> DCF take SR-IOV's mailbox as a message channel to communicate with the
> backend kernel driver, so iavf virtual channel is reused here, so we also need
> to link iavf share code.
> 
> And I agree, its always better if we can separate 2 different things while
> decouple all the common code into a share library to avoid duplicate code
> copy (just like we did on iavf share code) But in this case, a lot of code
> refectory is required , so far we just take the simple way, we may improve
> this in future.
> 
> Thanks
> Qi
> 
> >
> > Paul
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces at dpdk.org> On Behalf Of Haiyue Wang
> > > Sent: Monday, March 9, 2020 11:50 PM
> > > To: dev at dpdk.org; Ye, Xiaolong <xiaolong.ye at intel.com>; Zhang, Qi Z
> > > <qi.z.zhang at intel.com>; Yang, Qiming <qiming.yang at intel.com>; Xing,
> > > Beilei <beilei.xing at intel.com>
> > > Cc: Zhao1, Wei <wei.zhao1 at intel.com>; Wang, Haiyue
> > > <haiyue.wang at intel.com>
> > > Subject: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support
> > >
> > > A DCF (Device Config Function) based approach is proposed where a
> > > device bound to the device's VF0 can act as a sole controlling
> > > entity to exercise advance functionality (such as switch, ACL) for rest of
> the VFs.
> > >
> > > The DCF works as a standalone PMD to support this function, which
> > > shares the ice PMD flow control core function and the iavf virtchnl
> > > mailbox core module.
> > >
> > > This patchset is based on:
> > > [1] https://patchwork.dpdk.org/cover/66417/ : update ice base code
> > > [2] https://patchwork.dpdk.org/cover/66472/ : iavf share code update
> > >
> > > Depends-on: series-8843
> > > Depends-on: series-8855
> > >
> > > v2:
> > >    1. update the iavf patchset link.
> > >    2. split more patches for making this work be more understandable
> > >    3. fix the log function usage, devargs checking from v1.
> > >
> > > Haiyue Wang (7):
> > >   net/iavf: stop the PCI probe in DCF mode
> > >   net/ice: add the DCF hardware initialization
> > >   net/ice: initiate to acquire the DCF capability
> > >   net/ice: handle the AdminQ command by DCF
> > >   net/ice: export the DDP definition symbols
> > >   net/ice: handle the PF initialization by DCF
> > >   net/ice: get the VF hardware index in DCF
> > >
> > >  doc/guides/nics/ice.rst                |  47 ++
> > >  doc/guides/nics/img/ice_dcf.png        | Bin 0 -> 39168 bytes
> > >  doc/guides/rel_notes/release_20_05.rst |   5 +
> > >  drivers/common/Makefile                |   1 +
> > >  drivers/net/iavf/iavf_ethdev.c         |  43 ++
> > >  drivers/net/ice/Makefile               |   6 +
> > >  drivers/net/ice/ice_dcf.c              | 651
> > +++++++++++++++++++++++++
> > >  drivers/net/ice/ice_dcf.h              |  61 +++
> > >  drivers/net/ice/ice_dcf_ethdev.c       | 321 ++++++++++++
> > >  drivers/net/ice/ice_dcf_ethdev.h       |  33 ++
> > >  drivers/net/ice/ice_dcf_parent.c       | 344 +++++++++++++
> > >  drivers/net/ice/ice_ethdev.c           |   9 +-
> > >  drivers/net/ice/ice_ethdev.h           |   8 +
> > >  drivers/net/ice/meson.build            |   8 +-
> > >  mk/rte.app.mk                          |   1 +
> > >  15 files changed, 1528 insertions(+), 10 deletions(-)  create mode
> > > 100644 doc/guides/nics/img/ice_dcf.png  create mode 100644
> > > drivers/net/ice/ice_dcf.c  create mode 100644
> > > drivers/net/ice/ice_dcf.h create mode 100644
> > > drivers/net/ice/ice_dcf_ethdev.c  create mode 100644
> > > drivers/net/ice/ice_dcf_ethdev.h  create mode 100644
> > > drivers/net/ice/ice_dcf_parent.c
> > >
> > > --
> > > 2.25.1
> >
>