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

["Wang, Xiao W" <xiao.w.wang@intel.com>]

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
> I think it must be an port configuration, as Bruce suggested.
> What about a field in struct rte_eth_conf?