[dpdk-dev] disable i40e vf vlan stripping

[Olivier Matz]

Hi Jingjing,

On Wed, 29 Mar 2017 02:53:15 +0000, "Wu, Jingjing" <jingjing.wu at intel.com> wrote:
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> > Sent: Tuesday, March 28, 2017 11:30 PM
> > To: dev at dpdk.org; Zhang, Helin <helin.zhang at intel.com>; Wu, Jingjing
> > <jingjing.wu at intel.com>
> > Subject: disable i40e vf vlan stripping
> > 
> > Hi i40e maintainers,
> > 
> > I have the following configuration:
> > - host runs with Linux pf i40e driver
> > - guest runs with DPDK vf i40e driver
> > 
> > I send a vlan packet from the host to the guest.
> > On the guest, I start testpmd with --disable-hw-vlan-strip.
> > 
> > When I receive the packet on the guest, it has the PKT_RX_VLAN_STRIPPED flag
> > although I'm not asking for it. From what I understand, it is not possible to
> > disable vlan stripping when using a Linux PF driver.
> > 
> > Since the i40evf DPDK driver does not behave like what the application asks for,
> > I think it should be fixed. What do you think about re-adding the vlan in
> > software when dev_conf->rxmode.hw_vlan_strip == 0 ?
> > 
> > The other alternative would be to forbid this configuration and return an error.
> >   
> We faced the same issue with hw_crc_strip, and now the code is consider it as an error.
> The issue is hw_vlan_strip/hw_crc_strip mode is inconsistent between VF and PF.
> Evne I think it should not be an error to block the VF start up. But I'm fine if you think it is an error.
> 
> The ideal way maybe the capability negotiate between VF and PF. Let's think about it.

I'm not sure that you are suggesting to add an ethdev capability 
flag here, but I think that would be a bit odd. To clarify,
having flags to advertise the support of an offload feature makes
sense, but having flags to advertise that not using the offload is
supported looks strange.

Negotiating with the PF and returning an error if vlan_strip=0 is
not supported at port configuration, is the worst acceptable
option, because it prevents applications that do not handle offload
flags to work (which is probably the majority of applications).

I think that the best think to do, in terms of usability, is to
have a software fall-back in the driver that adds the vlan in the
packet data in that case. It would be transparent to the application.

To me, the "no offload" behavior is part of the basic features that
all PMDs should support (it could be interesting to have a list of
these features by the way).


Regards,
Olivier