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 545132C74 for ; Tue, 14 Mar 2017 14:32:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489498340; x=1521034340; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EXLTtDqOXWsIaiI+0LwbgOJdwZDHhUNPG8OdiJ1CRYg=; b=dtC7EJ9aMNoiQNQOlwp/hzMLCPe0q8RRNnugG0efbunUxzscNpTywo7Q 0HEfcMSVd/fcAaO2FXQz/fy+9/nD7g==; 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:32:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,163,1486454400"; d="scan'208";a="76478759" 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:32:15 -0700 To: "Zhang, Qi Z" , "Wu, Jingjing" , "Zhang, Helin" References: <20170303015924.68986-1-qi.z.zhang@intel.com> <20170303015924.68986-3-qi.z.zhang@intel.com> <8d111f4c-274d-e59f-1e7e-a2550b80d1bb@intel.com> <039ED4275CED7440929022BC67E7061153064A3C@SHSMSX103.ccr.corp.intel.com> Cc: "dev@dpdk.org" From: Ferruh Yigit Message-ID: <2f857fde-0149-9ee5-1d5a-3a664d205c08@intel.com> Date: Tue, 14 Mar 2017 13:32:15 +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: <039ED4275CED7440929022BC67E7061153064A3C@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] app/testpmd: enable VF untag drop in testpmd 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:32:20 -0000 On 3/9/2017 2:59 AM, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Tuesday, March 7, 2017 7:14 PM >> To: Zhang, Qi Z ; Wu, Jingjing ; >> Zhang, Helin >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 2/2] app/testpmd: enable VF untag drop in >> testpmd >> >> On 3/3/2017 1:59 AM, Qi Zhang wrote: >>> Add command line to support untag drop to specific VF in testpmd. >>> >>> Signed-off-by: Qi Zhang >>> --- >>> app/test-pmd/cmdline.c | 104 >>> +++++++++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 104 insertions(+) >>> >>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index >>> 43fc636..4ddc2c9 100644 >>> --- a/app/test-pmd/cmdline.c >>> +++ b/app/test-pmd/cmdline.c >>> @@ -311,6 +311,10 @@ static void cmd_help_long_parsed(void >>> *parsed_result, >>> >>> "set vf vlan antispoof (port_id) (vf_id) (on|off)\n" >>> " Set VLAN antispoof for a VF from the PF.\n\n" >>> +#ifdef RTE_LIBRTE_I40E_PMD >>> + "set vf vlan untagdrop (port_id) (vf_id) (on|off)\n" >>> + " Set VLAN untag drop for a VF from the PF.\n\n" >>> +#endif >> >> We should decide how to implement PMD specific APIs in testpmd, and be >> consistent about it. >> >> Currently there are two approaches: >> >> 1- Wrap PMD specific feature and API with and PMD #ifdef, as done here. >> >> 2- Enable feature by default, return -ENOTSUP for port_id that does not support >> it. Ex: cmd_vf_rxvlan_filter. >> >> I am for second option. And explicitly not disabling I40E driver does not mean >> you should have those NICs in your runtime environment, so the effect will be >> same as always enabling it. >> > Yes, I notice this problem, during implementation, I saw both patterns exist, so I have to choose one of them > We'd better align this. > Both option ok for me, but a little bit prefer option 1 , since it's not necessary to explore a command if no backend device, that make the hint more clean. I agree it's not necessary to explore a command if no backend device, but first option does not guaranties it. What it checks is compile time option, not runtime device detection. I40E driver is enabled by default, and unless user explicitly disables it, testpmd command will be there independent from device is there or not. >> >> And since number of PMD specific APIs are increasing, perhaps we should find a >> better approach for testpmd to prevent them corrupting testpmd. > Will think about this, also like to know if you or anyone have any good suggestion. >> >> Also it may worth to discuss why number of PMD specific APIs are increasing. >> >>> >>> "set vf vlan tag (port_id) (vf_id) (on|off)\n" >>> " Set VLAN tag for a VF from the PF.\n\n" >>> @@ -10995,6 +10999,103 @@ cmdline_parse_inst_t >> cmd_set_vf_vlan_anti_spoof = { >>> }, >>> }; >>> >> <...>