From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 826D529D2
 for <dev@dpdk.org>; Thu, 25 Feb 2016 14:35:22 +0100 (CET)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by orsmga101.jf.intel.com with ESMTP; 25 Feb 2016 05:35:21 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,498,1449561600"; d="scan'208";a="923717868"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.64])
 by fmsmga002.fm.intel.com with SMTP; 25 Feb 2016 05:35:18 -0800
Received: by  (sSMTP sendmail emulation); Thu, 25 Feb 2016 13:35:18 +0025
Date: Thu, 25 Feb 2016 13:35:18 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Chen, Jing D" <jing.d.chen@intel.com>
Message-ID: <20160225133518.GB20868@bricha3-MOBL3>
References: <1454410216-13333-2-git-send-email-xiao.w.wang@intel.com>
 <1454557129-12825-2-git-send-email-xiao.w.wang@intel.com>
 <20160224154255.GA21808@bricha3-MOBL3> <13026611.uCVrZtfrBT@xps13>
 <4341B239C0EFF9468EE453F9E9F4604D04450107@shsmsx102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4341B239C0EFF9468EE453F9E9F4604D04450107@shsmsx102.ccr.corp.intel.com>
Organization: Intel Shannon Ltd.
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2016 13:35:23 -0000

On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> Hi, Bruce, Thomas,
> 
> Best Regards,
> Mark
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Thursday, February 25, 2016 12:38 AM
> > To: Richardson, Bruce; Wang, Xiao W
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based
> > forwarding
> > 
> > 2016-02-24 15:42, Bruce Richardson:
> > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote:
> > > > This patch enables reading sglort info into mbuf for RX and inserting
> > > > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> > > > selected from rte_mbuf structure for sglort is not used in fm10k now.
> > > > In FTAG based forwarding mode, the switch will forward packets
> > according
> > > > to glort info in FTAG rather than mac and vlan table.
> > > >
> > > > To activate this feature, user needs to turn
> > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > > > to y in common_linuxapp or common_bsdapp. Currently this feature is
> > supported
> > > > only on PF, because FM10K_PFVTCTL register is read-only for VF.
> > > >
> > > > Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
> > >
> > > Any comments on this patch?
> > >
> > > My thoughts: is there a way in which this could be done without adding in a
> > new
> > > build time config option?
> > 
> > Bruce, it's simpler to explain that build time options are forbidden to
> > enable such options.
> > Or the terrific kid's approach: one day, the Big Build-Option Eater will come
> > and will eat every undecided features! ;)
> 
> This feature is trying to use FTAG (a unique tech in fm10k) instead of mac/vlan
> to forward packets. App need a way to tell PMD driver that which forwarding
> style it would like to use. 

Why not just specify this in the port configuration at setup time?

> So, the best option is to let packets carry a flag in mbuf to tell drive in fast path. 
> You can see that this is unique to fm10k and we thought community won't like to see 
> this flag introduced into mbuf. If you do agree, we can introduce a new flag.

Why does it need to be specified per-mbuf? The existing config flag added is
global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour.

> So, we step backwards and assume customer will use static configurations to enable
> this feature. After it is enabled, we'll assume app will use FTAG for all packets.

Yes, but instead of compile time option, why not port config-time option instead?

/Bruce