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 at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Thursday, February 25, 2016 12:38 AM > > To: Richardson, Bruce; Wang, Xiao W > > Cc: dev at 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 at 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
