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 B4DA23777 for ; Tue, 14 Mar 2017 15:43:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489502614; x=1521038614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1NGKlkfLl6KlkbgWjRv4mnQohp0aN4vNdsRVCr33JDA=; b=AOw1XxTTyORYINwmPiDVTHOqJgCWowG6tlUM/4XmBJUP6+nMay3Mh0FO Zr5LUy7uOqnIe8kVxuKYNU1+ceyVeQ==; Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 07:43:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,164,1486454400"; d="scan'208";a="944160213" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 14 Mar 2017 07:43:32 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Mar 2017 07:43:32 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Mar 2017 07:43:32 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002; Tue, 14 Mar 2017 22:43:29 +0800 From: "Zhang, Qi Z" To: "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 2/2] app/testpmd: enable VF untag drop in testpmd Thread-Index: AQHSk7q0JYm5pWVgGEC+yy7dd0rlEKGIujcAgAMNnUCACBljgIAAl0Zw Date: Tue, 14 Mar 2017 14:43:28 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153066701@SHSMSX103.ccr.corp.intel.com> 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> <2f857fde-0149-9ee5-1d5a-3a664d205c08@intel.com> In-Reply-To: <2f857fde-0149-9ee5-1d5a-3a664d205c08@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzYwYzAyZGEtN2I3Yy00NTEyLWJlNDAtNWZjNzUyNDMzNmVlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImRKeHZIbTNyNHAxNHZuajZqK1FobUVqR0VYSVJOUW1kdHdpSTd0SHlqaWs9In0= 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 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 14:43:35 -0000 > -----Original Message----- > From: Yigit, Ferruh > Sent: Tuesday, March 14, 2017 9:32 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 >=20 > 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 no= t > necessary to explore a command if no backend device, that make the hint > more clean. >=20 > 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 optio= n, 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. So this still benefit custom build, right? Anyway, as I said, both are ok for me, I followed option 2 since most APIs = follow this. Please check v2. >=20 > >> > >> 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 =3D { > >>> }, > >>> }; > >>> > >> <...>