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

Wang, Xiao W xiao.w.wang at intel.com
Mon Feb 29 02:47:55 CET 2016



> -----Original Message-----
> From: Richardson, Bruce
> Sent: Saturday, February 27, 2016 12:33 AM
> To: David Marchand <david.marchand at 6wind.com>
> Cc: Wang, Xiao W <xiao.w.wang at intel.com>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
> 
> On Fri, Feb 26, 2016 at 04:00:49PM +0100, David Marchand wrote:
> > On Fri, Feb 26, 2016 at 3:48 PM, Bruce Richardson
> > <bruce.richardson at intel.com> 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 glort
> (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=1
> >
> > 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?
> 
> /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


More information about the dev mailing list