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 ABA7D2A6C for ; Mon, 29 Feb 2016 02:47:59 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Feb 2016 17:47:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,518,1449561600"; d="scan'208";a="897049819" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 28 Feb 2016 17:47:58 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 28 Feb 2016 17:47:58 -0800 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; Sun, 28 Feb 2016 17:47:57 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.42]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 09:47:56 +0800 From: "Wang, Xiao W" To: "Richardson, Bruce" , David Marchand Thread-Topic: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding Thread-Index: AQHRXv2babUM9wifAkaFm8+HJNJY45867/aAgAAPUoCAASRUAIAAOwcAgAAkc4CAAAfsAIABMycA///npwCAAIggUP//15YAgAADV4CAABnMgIAEQuaw Date: Mon, 29 Feb 2016 01:47:55 +0000 Message-ID: References: <1454410216-13333-2-git-send-email-xiao.w.wang@intel.com> <20160225161406.GA22772@bricha3-MOBL3> <4126401.C51dJZWCEs@xps13> <20160226144852.GC21628@bricha3-MOBL3> <20160226163309.GA28808@bricha3-MOBL3> In-Reply-To: <20160226163309.GA28808@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 01:48:00 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Saturday, February 27, 2016 12:33 AM > To: David Marchand > Cc: Wang, Xiao W ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwardin= g >=20 > On Fri, Feb 26, 2016 at 04:00:49PM +0100, David Marchand wrote: > > On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson > > wrote: > > > On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote: > > >> Hi, > > >> > > Thanks for the discussion, Thomas, do you have any suggestions? > > >> > > > >> > I don't understand why you say this feature is specific to fm10k. > > >> > Can we imagine another NIC having this capability? > > >> > > >> As you know, fm10k has a switch logic between the Mac and Phy, > > >> every packets Sent out from the host will be switched inside the > > >> NIC, other NICs don't have a switch inside, and the FTAG feature is = related > to the switch function. > > >> > > >> As introduced in the second patch: > > >> The FM10K family of NICs support the addition of a Fabric Tag > > >> (FTAG) to carry special information. The FTAG is placed at the > > >> beginning of the frame, it contains information such as where the > > >> packet comes from and goes, and the vlan tag. In FTAG based > > >> forwarding mode, the switch logic forwards packets according to glor= t > (global resource tag) information, rather than the mac and vlan table. > > >> So this is a feature specific to fm10k. > > > > > > If it is fm10k specific, how about just adding a public function to > > > the fm10k driver to turn it on. The user app will be non-portable > > > across NICs, but that's the price of using nic-specific features. > > > > What about using a devargs ? > > Something like : > > -w xxxx:xx:xx.x,enable_ftag=3D1 > > > > The application still needs to know about this to enable it, but that > > sounds better to me. > > The only issue is that it can't work with hotplug at the moment. > > > Seems a good enough solution to me. Xiao, any other thoughts? >=20 > /Bruce I also agree with the devargs solution, in this way, the build time config = can be removed and we don't need to add extra fields into ethdev. I'll rework the patch, thanks for the suggestions. Best Regards, Xiao