From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 387002C74 for ; Tue, 14 Mar 2017 14:29:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489498176; x=1521034176; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qxnh0r3Db0uFb6utIqm+eLvP2B9+XYH95ta/Lfk5+U4=; b=kl2XEXGjGBlsk3dRz25wauuYcUdXL8d5IqhWa1/eBCbRKIGGde2BX03P 1CmkUQtH3V7OAoC71qPwug92Z/CsLw==; Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 06:29:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,163,1486454400"; d="scan'208,217";a="76477691" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.122]) ([10.237.220.122]) by fmsmga006.fm.intel.com with ESMTP; 14 Mar 2017 06:29:33 -0700 To: "Zhang, Qi Z" , "Wu, Jingjing" , "Zhang, Helin" 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> Cc: "dev@dpdk.org" From: Ferruh Yigit Message-ID: <30438962-6669-6a90-66bc-fb43416135d5@intel.com> Date: Tue, 14 Mar 2017 13:29:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <039ED4275CED7440929022BC67E7061153064A90@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 13:29:36 -0000 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: >> __, for this API it becomes: > I think, current naming rule is __ right? 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. 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 am OK. >> >> rte_pmd_i40e_vf_vlan_untag_drop_set(), and perhaps "set" can be removed? >> >>> + >>> #endif /* _PMD_I40E_H_ */ >>> >