Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Feb 26, 2016 at 09:24:06AM +0000, Wang, Xiao W wrote:
> Hi,
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Friday, February 26, 2016 5:06 PM
> > To: Wang, Xiao W <xiao.w.wang@intel.com>
> > Cc: Richardson, Bruce <bruce.richardson@intel.com>; Chen, Jing D
> > <jing.d.chen@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> > 
> > 2016-02-26 04:31, Wang, Xiao W:
> > > From: Richardson, Bruce
> > > > On Thu, Feb 25, 2016 at 03:45:45PM +0000, Chen, Jing D wrote:
> > > > > From: Richardson, Bruce
> > > > > > On Thu, Feb 25, 2016 at 10:04:02AM +0000, Chen, Jing D wrote:
> > > > > > > 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?
> > > > > >
> > > > >
> > > > > Please educate me. I think the port configuration flags are also
> > > > > common to all PMD Drivers. Is it possible to add a flag like
> > "RTE_USE_FTAG"
> > > > and pass to PMD driver?
> > > > >
> > > > They are.
> > > > For something PMD specific, like FTAG, it's always a challenge, and
> > > > I don't know off the top of my head if there is a simple option.
> > > > However, given the choice between an mbuf flag and a port config
> > > > flag, I'd always choose the former.
> > > > Other alternatives would be to have a fm10k specific API in the
> > > > fm10k driver alone.
> > > >
> > > > I'll let Thomas as ethdev maintainer comment if he has other
> > > > suggestions as to how to handle this case. I suspect this won't be
> > > > the first device-specific piece of functionality we need to deal with.
> > > >
> > > > /Bruce
> > >
> > > Whatever method we choose, we have to find a way for the user to
> > > express his need for FTAG, it maybe a build time config option, or a
> > > port config flag (no such flag now), or a fast path flag in mbuf (no
> > > such flag now) etc. For the customer Topsec's use case, they use FTAG
> > > for all the TX packets, so all the above methods (per build config,
> > > per port config, per mbuf config) can meet their need. Since the pmd
> > > frame work is for common, it's hard to add new fields only for one specific
> > NIC, so I add a build time config and make an introduction in the doc.
> > >
> > > 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
> glort (global resource tag) information, rather than the mac and vlan table.
> So this is a feature specific to fm10k.
> 
> Best Regards,
> Xiao

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.

/Bruce

> > I think it must be an port configuration, as Bruce suggested.
> > What about a field in struct rte_eth_conf?