Subject: Re: [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle

From: Michal Schmidt <[email-masked]>
Date: Wed, 31 Aug 2011 15:53:24 +0200

On Wed, 31 Aug 2011 15:01:39 +0300 Vlad Zolotarov wrote:
> On Tuesday 30 August 2011 22:30:11 Michal Schmidt wrote:
> 
> > > and then also in fp->flags.  Are the
> > > fp->flags strictly mirroring hardware state (as in: there is no
> > > way the states can differ in any point in time where the flags are
> > > tested)?
> > 
> > Yes. This is the purpose of the second mirroring of the flag.
> 
> Michal,
> although the above is true i'd say it's a bit of an overkill:
> RX VLAN stripping is configured in a function level, so keeping it in
> a per queue level is not needed. 
> 
> The problem u were trying to resolve (and u resolved it) was to
> separate the RX_VLAN_ENABLED flag semantics into two: requested
> feature and HW configured feature in order to further check the
> second in the fast path, while setting the first one in the
> set_features(). Then the second lag is updated according to the first
> one during the loading of the function (bnx2x_nic_load()).
> 
> Therefore it would be enough to just add those two flags in the
> function (bp) level keeping the rest of your patch as it is. This
> would also cancel the need for a patch 6.

Alright, I will remove the per-fp flag and move it to bp.

I will also apply the cheat suggested by Michał, so that:
 - dev->features & NETIF_F_HW_VLAN_RX is the requested state
 - bp->flags & RX_VLAN_STRIP_FLAG is the HW configured state
=> Only one new bp flag needed, not two.

BTW, Michał's cheat should apply to TPA_ENABLE_FLAG as well - it only
mirrors NETIF_F_LRO. But for TPA the HW configured state is really
per-queue (fp->disable_tpa). I will remove TPA_ENABLE_FLAG unless you
object to Michał's "cheat".

Thanks,
Michal