See my responses inline. Paul
> -----Original Message----- > From: Zhang, Qi Z <qi.z.zh...@intel.com> > Sent: Saturday, March 14, 2020 6:50 PM > To: Stillwell Jr, Paul M <paul.m.stillwell...@intel.com>; Wang, Haiyue > <haiyue.w...@intel.com>; dev@dpdk.org; Ye, Xiaolong > <xiaolong...@intel.com>; Yang, Qiming <qiming.y...@intel.com>; Xing, > Beilei <beilei.x...@intel.com> > Cc: Zhao1, Wei <wei.zh...@intel.com>; Wang, Haiyue > <haiyue.w...@intel.com>; Liang, Cunming <cunming.li...@intel.com>; Wu, > Jingjing <jingjing...@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...@intel.com> > > Sent: Saturday, March 14, 2020 12:19 AM > > To: Wang, Haiyue <haiyue.w...@intel.com>; dev@dpdk.org; Ye, Xiaolong > > <xiaolong...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>; Yang, > > Qiming <qiming.y...@intel.com>; Xing, Beilei <beilei.x...@intel.com> > > Cc: Zhao1, Wei <wei.zh...@intel.com>; Wang, Haiyue > > <haiyue.w...@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-boun...@dpdk.org> On Behalf Of Haiyue Wang > > > Sent: Monday, March 9, 2020 11:50 PM > > > To: dev@dpdk.org; Ye, Xiaolong <xiaolong...@intel.com>; Zhang, Qi Z > > > <qi.z.zh...@intel.com>; Yang, Qiming <qiming.y...@intel.com>; Xing, > > > Beilei <beilei.x...@intel.com> > > > Cc: Zhao1, Wei <wei.zh...@intel.com>; Wang, Haiyue > > > <haiyue.w...@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 > > >