From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id AE2C63777 for ; Tue, 14 Mar 2017 19:16:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489515390; x=1521051390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+kb8+QzqxQnA970zUUx/XA4hj5P4QIpMwMbJfV3reXE=; b=aBuku1xpGzm+KM1MaNT3N3aeODDS2/5XbnoNddhsFJ7cKQM/njhdgtOX DD4PWCOHCtHo3ZXC0q2BxF5mNf+wqg==; Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 11:16:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,165,1486454400"; d="scan'208,217";a="76599462" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga006.fm.intel.com with ESMTP; 14 Mar 2017 11:16:28 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX107.ger.corp.intel.com (163.33.3.99) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Mar 2017 18:16:27 +0000 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by irsmsx155.ger.corp.intel.com ([169.254.14.204]) with mapi id 14.03.0248.002; Tue, 14 Mar 2017 18:16:27 +0000 From: "Iremonger, Bernard" To: "Zhang, Qi Z" , "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/2] net/i40e: enable VF untag drop Thread-Index: AQHSk7rHPFbJmUsTzkmiWkNcog2reqGJOf4AgAKn3QCACIS3gIAAEbeAgAA7mXA= Date: Tue, 14 Mar 2017 18:16:27 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C224D34EF2@IRSMSX108.ger.corp.intel.com> References: <20170303015924.68986-1-qi.z.zhang@intel.com> <20170303015924.68986-2-qi.z.zhang@intel.com> <99df9cb9-cbad-d41a-7b99-2888e4f926cb@intel.com> <039ED4275CED7440929022BC67E7061153064A90@SHSMSX103.ccr.corp.intel.com> <30438962-6669-6a90-66bc-fb43416135d5@intel.com> <039ED4275CED7440929022BC67E70611530666DF@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <039ED4275CED7440929022BC67E70611530666DF@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDk1Y2YyYjItZWVjZC00ZjViLTkwMGMtMmEyYTY5OWNkODRjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlhlWFR2d05ESHpLVlB6XC9xYVVBRGhoV2ZCakNKUFhXREtZZVZHSXY3TXhVPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: enable VF untag drop 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: , X-List-Received-Date: Tue, 14 Mar 2017 18:16:31 -0000 Hi Ferruh, Qi, > > >> Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: enable VF untag drop > > >> > > >> On 3/3/2017 1:59 AM, Qi Zhang wrote: > > >>> Add a new private API to support the untag drop enable/disable for > > >>> specific VF. > > >>> > > >>> Signed-off-by: Qi Zhang > > >>> --- > > >>> drivers/net/i40e/i40e_ethdev.c | 49 > > >>> +++++++++++++++++++++++++++++++++++++++++ > > >>> drivers/net/i40e/rte_pmd_i40e.h | 18 +++++++++++++++ > > >> > > >> Shared library is giving build error because of API is missing in > > >> *version.map file > > >> > > >>> 2 files changed, 67 insertions(+) > > >>> > > >> > > >> <...> > > >> > > >>> diff --git a/drivers/net/i40e/rte_pmd_i40e.h > > >>> b/drivers/net/i40e/rte_pmd_i40e.h index a0ad88c..895e2cc 100644 > > >>> --- a/drivers/net/i40e/rte_pmd_i40e.h > > >>> +++ b/drivers/net/i40e/rte_pmd_i40e.h > > >>> @@ -332,4 +332,22 @@ int rte_pmd_i40e_get_vf_stats(uint8_t port, > > >>> int rte_pmd_i40e_reset_vf_stats(uint8_t port, > > >>> uint16_t vf_id); > > >>> > > >>> +/** > > >>> + * Enable/Disable VF untag drop > > >>> + * > > >>> + * @param port > > >>> + * The port identifier of the Ethernet device. > > >>> + * @param vf_id > > >>> + * VF on witch to enable/disable > > >>> + * @param on > > >>> + * Enable or Disable > > >>> + * @retura > > >> > > >> @return > > >> > > >>> + * - (0) if successful. > > >>> + * -(-ENODEVE) if *port* invalid > > >>> + * -(-EINVAL) if bad parameter. > > >>> + */ > > >>> +int rte_pmd_i40e_set_vf_vlan_untag_drop(uint8_t port, > > >>> + uint16_t vf_id, > > >>> + uint8_t on); > > >> > > >> As discussed previously, I believe it is good to keep following > > >> syntax in > > API: > > >> __, for this API it becomes: > > > I think, current naming rule is __ right? This seems to be the existing naming convention. > > > > Overall, I am not aware of any defined naming rule, I am for defining o= ne. > > > > > See below > > > rte_pmd_i40e_set_vf_vlan_anti_spoof; > > > rte_pmd_i40e_set_vf_vlan_filter; > > > rte_pmd_i40e_set_vf_vlan_insert; > > > rte_pmd_i40e_set_vf_vlan_stripq; > > > rte_pmd_i40e_set_vf_vlan_tag; so what's wrong with this > > > > This breaks hierarchical approach, if you think API name as tree. > > Easier to see this when you sort the APIs, ns_set_x, ns_reset_x, > > ns_del_x will spread to different locations. > I agree with your point, I had thought your concern is only about this pa= tch, > but actually it's not. > > > > This looks OK when you work on one type of object already, but with > > all APIs in concern, I believe object based grouping is better than > > action based grouping. >=20 > > > > And why do you think above one is better? Again, as long as one is > > agreed on, > I don't, sorry for make you misunderstand I don't think changing the name convention at this point is a good idea. It would be better to remain consistent with the existing naming convention= . Otherwise both naming conventions will exist for the rte_pmd_i40e_* API's. =20 > > >> rte_pmd_i40e_vf_vlan_untag_drop_set(), and perhaps "set" can be > > removed? > > >> > > >>> + > > >>> #endif /* _PMD_I40E_H_ */ > > >>> > > > Regards, Bernard.