From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9D3EEA0576; Fri, 13 Mar 2020 18:05:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E2E6F2BE3; Fri, 13 Mar 2020 18:05:18 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 9DFE11AFF for ; Fri, 13 Mar 2020 18:05:16 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2020 10:05:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,549,1574150400"; d="scan'208";a="442482674" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga005.fm.intel.com with ESMTP; 13 Mar 2020 10:05:12 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 13 Mar 2020 10:05:10 -0700 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sat, 14 Mar 2020 01:05:08 +0800 Received: from shsmsx603.ccr.corp.intel.com ([10.109.6.143]) by SHSMSX603.ccr.corp.intel.com ([10.109.6.143]) with mapi id 15.01.1713.004; Sat, 14 Mar 2020 01:05:08 +0800 From: "Wang, Haiyue" To: "Stillwell Jr, Paul M" , "dev@dpdk.org" , "Ye, Xiaolong" , "Zhang, Qi Z" , "Yang, Qiming" , "Xing, Beilei" CC: "Zhao1, Wei" Thread-Topic: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support Thread-Index: AQHV9qlIvRFE+hfqn0Svmk6VBB99+6hGMsmAgACGXfD//4JRgIAAiH1w Date: Fri, 13 Mar 2020 17:05:08 +0000 Message-ID: References: <20200309141437.11800-1-haiyue.wang@intel.com> <20200310065029.40966-1-haiyue.wang@intel.com> <54faf82423d94f85a83298f9238b9ac1@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Paul, > -----Original Message----- > From: Stillwell Jr, Paul M > Sent: Saturday, March 14, 2020 00:50 > To: Wang, Haiyue ; dev@dpdk.org; Ye, Xiaolong ; Zhang, > Qi Z ; Yang, Qiming ; Xing, = Beilei > Cc: Zhao1, Wei > Subject: RE: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support >=20 > Hi Haiyue, >=20 > This statement is confusing to me "But the flow setting is the ice PF Adm= inQ message, so the DCF > shares most of ice PMD flow control." What do you mean by "flow setting"?= =20 It is DPDP rte_flow API calling. > The way I understand DCF > working is that there is a trusted VF (the DCF) that is setting switch ru= les for other VFs on the same > PF. The mechanism for doing that is the DCF sends a virtchnl message to t= he Linux kernel driver PF to DCF needs: 1). virtchnl message is handles by 'dpdk/drivers/common/iavf/', = which is the original iavf base code. > add/delete a switch rule. None of this requires the ice PMD as far as I c= an tell. This seems like a DCF needs: 2). add/delete a switch rule. rte_flow API --> 'dpdk/drivers/net/ice/ice_switch_filter.c/i= ce_generic_flow.c' (ice flow framework) | `--> 'dpdk/drivers/net/ice/base' ... So, put it under the ice PMD is the best way. > driver just like the iavf driver; the iavf driver is separate from the ic= e PMD and it seems like DCF > should also be separate. >=20 > Paul >=20 > > -----Original Message----- > > From: Wang, Haiyue > > Sent: Friday, March 13, 2020 9:25 AM > > To: Stillwell Jr, Paul M ; dev@dpdk.org;= Ye, > > Xiaolong ; Zhang, Qi Z ; > > Yang, Qiming ; Xing, Beilei > > Cc: Zhao1, Wei > > Subject: RE: [dpdk-dev] [PATCH v2 0/7] add Intel DCF PMD support > > > > Hi Paul, > > > > Yes, it's VF (VF hardware initialization like virtchnl). But the flow s= etting is the > > ice PF AdminQ message, so the DCF shares most of ice PMD flow control. > > > > BR, > > Haiyue > > > > > -----Original Message----- > > > From: Stillwell Jr, Paul M > > > Sent: Saturday, March 14, 2020 00:19 > > > To: Wang, Haiyue ; dev@dpdk.org; Ye, Xiaolong > > > ; Zhang, Qi Z ; Yang, > > > Qiming ; Xing, Beilei > > > Cc: Zhao1, Wei ; Wang, Haiyue > > > > > > 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. > > > > > > Paul > > > > > > > -----Original Message----- > > > > From: dev On Behalf Of Haiyue Wang > > > > Sent: Monday, March 9, 2020 11:50 PM > > > > To: dev@dpdk.org; Ye, Xiaolong ; Zhang, Qi Z > > > > ; Yang, Qiming ; Xing, > > > > Beilei > > > > Cc: Zhao1, Wei ; Wang, Haiyue > > > > > > > > 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 updat= e > > > > > > > > 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 understandabl= e > > > > 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 > > > > > >=20