From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A7CB114E8 for ; Thu, 23 Mar 2017 18:22:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490289771; x=1521825771; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+WZIiTpKb8TjMPuvuZF+VXJ7pBo6kWl1KxXJrEWvqbw=; b=AU9+8jFv0A2s+WMN5cZyIBXx3esvYa28wFBOoC+CRQGejHM/8B6O7zuZ +yFdPR9xgn556il487veHd/rvhm0bw==; Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 10:22:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,210,1486454400"; d="scan'208,217";a="947514354" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga003.jf.intel.com with ESMTP; 23 Mar 2017 10:22:49 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by IRSMSX152.ger.corp.intel.com ([169.254.6.125]) with mapi id 14.03.0248.002; Thu, 23 Mar 2017 17:22:48 +0000 From: "Iremonger, Bernard" To: "Yigit, Ferruh" , "Zhang, Qi Z" , "Wu, Jingjing" , "Zhang, Helin" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/2] net/i40e: enable VF untag drop Thread-Index: AQHSk7rHPFbJmUsTzkmiWkNcog2reqGJOf4AgAKn3QCACIS3gIAAEbeAgAA7mXCADhJ9AIAAAzjA Date: Thu, 23 Mar 2017 17:22:47 +0000 Message-ID: <8CEF83825BEC744B83065625E567D7C224D3870E@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> <8CEF83825BEC744B83065625E567D7C224D34EF2@IRSMSX108.ger.corp.intel.com> <61684a15-2647-06ff-dcc9-02d030b77b20@intel.com> In-Reply-To: <61684a15-2647-06ff-dcc9-02d030b77b20@intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTAxOGUwYzYtMzg2Yy00NmM3LTgwYjctODhmMDk1NzVhMjI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjRNWTgzMFo2NDVBb2thXC9zNkpVU0s5NHVnSGMzVFM2WFV5SlpCc2lNYnZRPSJ9 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: Thu, 23 Mar 2017 17:22:52 -0000 Hi Ferruh, > >>>>> 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 > one. > >>> > >>>> 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 patch, 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. > >> > >>> > >>> 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= . >=20 > I am not suggesting changing existing ones, for the sake compatibility. > But that can also be an option, since these are PMD specific API, I expec= t > usage will be limited and these does not carry as high standard as librar= y APIs. These API's are already in use with users.=20 > > It would be better to remain consistent with the existing naming > convention. >=20 > Existing i40e ones added this way to be compatible with existing ixgbe on= es. > But I don't think we need to follow old usage with new APIs. >=20 > > Otherwise both naming conventions will exist for the rte_pmd_i40e_* > API's. >=20 > It can be for a while, later all can be fixed. If you think proposed conv= ention is > not better, that is something else. I don't see anything to be gained by using two naming conventions side by s= ide. I don't have a strong view on which name convention is better, however the = existing naming convention is what is in use with users at present. It is a= lso the naming convention used librte_ether. Changing API naming conventions is something that should probably be discus= sed in a separate thread, as it can have a wider impact than the i40e and i= xgbe PMD's. =20 > > > > > >>>>> rte_pmd_i40e_vf_vlan_untag_drop_set(), and perhaps "set" can be > >>> removed? > >>>>> > >>>>>> + > >>>>>> #endif /* _PMD_I40E_H_ */ > >>>>>> > >>>> Regards, Bernard.