[dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping for i40evf

[Zhang, Helin]

> -----Original Message-----
> From: Topel, Bjorn
> Sent: Wednesday, November 9, 2016 7:28 PM
> To: Ananyev, Konstantin; dev at dpdk.org; Zhang, Helin
> Cc: Xu, Qian Q; Yao, Lei A; Wu, Jingjing; thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping for
> i40evf
> 
> >> Correct, so the broader question would be "what is the correct
> >> behavior for an example application, when a port configuration isn't
> >> supported by the hardware?".
> >>
> >> My stand, FWIW, is that igb and ixgbe should have the same semantics
> >> as i40e currently has, i.e. return an error to the user if the port
> >> is mis-configured, NOT changing the setting behind the users back.
> >>
> >
> > Fine by me, but then it means that the fix haw to include changes for
> > all apps plus ixgbe and igb PMDs, correct? :)
> 
> Ugh. Correct, I guess. :-)
> 
> As for ixgbe and igb - they need a patch changing from silent ignore to
> explicit error. Regarding the apps, I guess all the apps that rely on that
> disabling CRC stripping always work, need some work. Or should all the
> example applications have CRC stripping *enabled* by default? I'd assume
> that all DPDK supported NICs has support for CRC stripping and I guess this is
> the rational for having it on by default for Intel VFs.
> 
> In general, for the example applications, if an application relies on a property
> for a port, that the hardware doesn't support -- what would be the desired
> behavior? Or is it implied that the example applications only use a common,
> minimal set of features that are know to be supported by all DPDK supported
> hardware?
> 
> Isn't it perfectly valid that some example applications wont run for all
> hardware?
> 
> Finally, why doesn't l3fwd have the CRC stripped?
> 
> 
> Björn

Yes, i40e driver changed a little bit on that according to the review comments
during implementation, comparing to igb and ixgbe.
I'd suggest to re-invesitgate if we can do the similar thing in igb and ixgbe driver.
Any critical issue now? Or just an improvement comments?

Thanks,
Helin