From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 77A732C74 for ; Tue, 14 Mar 2017 15:33:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489502004; x=1521038004; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ioFCShS/V6eTgt0FOHiN2xGzERwNzvcWx7sXyzBR10I=; b=CjEM1OUMSLc4vX/eZrJggcGgtg1UUywOxfCozDvA2gHURDpDnMxVzjAA 5A4GjyjD7G2ydxW2YoKnzPHmdjGlBw==; Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 07:33:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,164,1486454400"; d="scan'208";a="834469534" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 14 Mar 2017 07:33:00 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Mar 2017 07:33:00 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Mar 2017 07:32:59 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0248.002; Tue, 14 Mar 2017 22:32:57 +0800 From: "Zhang, Qi Z" To: "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: AQHSk7qx73Q6lNzHP0aPTYZG6rC406GIs+IAgAMtUiCAB/9CgIAAjj9Q Date: Tue, 14 Mar 2017 14:32:57 +0000 Message-ID: <039ED4275CED7440929022BC67E70611530666DF@SHSMSX103.ccr.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> In-Reply-To: <30438962-6669-6a90-66bc-fb43416135d5@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDk1Y2YyYjItZWVjZC00ZjViLTkwMGMtMmEyYTY5OWNkODRjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlhlWFR2d05ESHpLVlB6XC9xYVVBRGhoV2ZCakNKUFhXREtZZVZHSXY3TXhVPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] 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 14:33:25 -0000 > -----Original Message----- > From: Yigit, Ferruh > Sent: Tuesday, March 14, 2017 9:30 PM > To: Zhang, Qi Z ; Wu, Jingjing > ; Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: enable VF untag drop >=20 > On 3/9/2017 3:24 AM, Zhang, Qi Z wrote: > > Hi Ferruh: > > > >> -----Original Message----- > >> From: Yigit, Ferruh > >> Sent: Tuesday, March 7, 2017 6:51 PM > >> To: Zhang, Qi Z ; Wu, Jingjing > >> ; Zhang, Helin > >> Cc: dev@dpdk.org > >> 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:=09 > >> __, for this API it becomes: > > I think, current naming rule is __ right? >=20 > Overall, I am not aware of any defined naming rule, I am for defining one= . >=20 > > 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=20 >=20 > 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 spre= ad > to different locations. I agree with your point, I had thought your concern is only about this patc= h, but actually it's not. >=20 > This looks OK when you work on one type of object already, but with all A= PIs > 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 >=20 > >> > >> rte_pmd_i40e_vf_vlan_untag_drop_set(), and perhaps "set" can be > removed? > >> > >>> + > >>> #endif /* _PMD_I40E_H_ */ > >>> > >