From: "Vlad Zolotarov" <vladz@broadcom•com>
To: "Michal Schmidt" <mschmidt@redhat•com>
Cc: "Michał Mirosław" <mirqus@gmail•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Dmitry Kravkov" <dmitry@broadcom•com>,
"Eilon Greenstein" <eilong@broadcom•com>
Subject: Re: [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle
Date: Wed, 31 Aug 2011 18:07:53 +0300 [thread overview]
Message-ID: <201108311807.53767.vladz@broadcom.com> (raw)
In-Reply-To: <20110831155324.7554d035@alice>
On Wednesday 31 August 2011 16:53:24 Michal Schmidt wrote:
> 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".
I agree the TPA_ENABLE_FLAG may and should be removed.
However I didn’t like the idea of relying on the current implementation
of the calling function (__netdev_update_features()). If u want to change
the implementation the way we rely on the dev->features in the
ndo_set_features() flow, which is a semantics change, u'd rather change
the __netdev_update_features() so that it sets the dev->features before
ndo_set_features() call and restores it in case of a failure. Something like this:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a7f619..a5f6d3e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -943,8 +943,7 @@ struct net_device_ops {
struct net_device *slave_dev);
u32 (*ndo_fix_features)(struct net_device *dev,
u32 features);
- int (*ndo_set_features)(struct net_device *dev,
- u32 features);
+ int (*ndo_set_features)(struct net_device *dev);
};
/*
diff --git a/net/core/dev.c b/net/core/dev.c
index b2e262e..474e539 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5321,7 +5321,7 @@ static u32 netdev_fix_features(struct net_device *dev, u32 features)
int __netdev_update_features(struct net_device *dev)
{
- u32 features;
+ u32 features, old_features;
int err = 0;
ASSERT_RTNL();
@@ -5340,19 +5340,23 @@ int __netdev_update_features(struct net_device *dev)
netdev_dbg(dev, "Features changed: 0x%08x -> 0x%08x\n",
dev->features, features);
+ /* Remember the original features and set the new ones */
+ old_features = dev->features;
+ dev->features = features;
+
if (dev->netdev_ops->ndo_set_features)
- err = dev->netdev_ops->ndo_set_features(dev, features);
+ err = dev->netdev_ops->ndo_set_features(dev);
if (unlikely(err < 0)) {
+ /* Restore the original features */
+ dev->features = old_features;
+
netdev_err(dev,
"set_features() failed (%d); wanted 0x%08x, left 0x%08x\n",
err, features, dev->features);
return -1;
}
- if (!err)
- dev->features = features;
-
return 1;
}
However, this would involve updating all other L2 drivers that implement ndo_set_features().
Pls., comment.
thanks,
vlad
>
> Thanks,
> Michal
next prev parent reply other threads:[~2011-08-31 15:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 14:30 [PATCH 0/7 net-next] bnx2x: cleanups and VLAN stripping toggle Michal Schmidt
2011-08-30 14:30 ` [PATCH 1/7] bnx2x: remove unused fields in struct bnx2x_func_init_params Michal Schmidt
2011-08-31 10:07 ` Vlad Zolotarov
2011-08-30 14:30 ` [PATCH 2/7] bnx2x: remove the 'leading' arguments Michal Schmidt
2011-08-31 9:57 ` Vlad Zolotarov
2011-08-30 14:30 ` [PATCH 3/7] bnx2x: decrease indentation in bnx2x_rx_int() Michal Schmidt
2011-08-31 10:33 ` Vlad Zolotarov
2011-08-30 14:30 ` [PATCH 4/7] bnx2x: simplify TPA sanity check Michal Schmidt
2011-08-31 10:22 ` Vlad Zolotarov
2011-08-30 14:30 ` [PATCH 5/7] bnx2x: do not set TPA flags and features in bnx2x_init_bp Michal Schmidt
2011-08-30 16:21 ` Vlad Zolotarov
2011-08-30 17:15 ` Michal Schmidt
2011-08-30 14:30 ` [PATCH 6/7] bnx2x: move fp->disable_tpa to ->flags Michal Schmidt
2011-08-30 14:30 ` [PATCH 7/7] bnx2x: expose HW RX VLAN stripping toggle Michal Schmidt
2011-08-30 18:27 ` Michał Mirosław
2011-08-30 19:30 ` Michal Schmidt
2011-08-30 20:08 ` Michał Mirosław
2011-08-31 12:01 ` Vlad Zolotarov
2011-08-31 13:53 ` Michal Schmidt
2011-08-31 15:07 ` Vlad Zolotarov [this message]
2011-08-31 15:37 ` Michal Schmidt
2011-08-31 15:51 ` Michal Schmidt
2011-08-31 16:16 ` Vlad Zolotarov
2011-08-31 18:11 ` Michał Mirosław
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201108311807.53767.vladz@broadcom.com \
--to=vladz@broadcom$(echo .)com \
--cc=dmitry@broadcom$(echo .)com \
--cc=eilong@broadcom$(echo .)com \
--cc=mirqus@gmail$(echo .)com \
--cc=mschmidt@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox