From: Dave Dillow <dave@thedillows.org>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Re: [PATCH] deinline a few large functions in vlan code v2
Date: Tue, 11 Apr 2006 09:59:44 -0400 [thread overview]
Message-ID: <1144763984.16193.9.camel@dillow.idleaire.com> (raw)
In-Reply-To: <200604111028.54813.vda@ilport.com.ua>
On Tue, 2006-04-11 at 10:28 +0300, Denis Vlasenko wrote:
> > > > > block? For example, typhoon.c:
> > > > >
> > > > > spin_lock(&tp->state_lock);
> > > > > +#if defined(CONFIG_VLAN_8021Q) || defined (CONFIG_VLAN_8021Q_MODULE)
> > > > > if(tp->vlgrp != NULL && rx->rxStatus & TYPHOON_RX_VLAN)
> > > > > vlan_hwaccel_receive_skb(new_skb, tp->vlgrp,
> > > > > ntohl(rx->vlanTag) & 0xffff);
> > > > > else
> > > > > +#endif
> > > > > netif_receive_skb(new_skb);
> > > > > spin_unlock(&tp->state_lock);
> > > > >
> > > > > Same for s2io.c, chelsio/sge.c, etc...
> > > >
> > > > Very likely yes. tp->vlgrp will never be non-NULL in such situations
> > > > so it's not a correctness issue, but rather an optimization :-)
> >
> > I see this as a minor optimization, at the cost uglifying the body of a
> > function.
>
> But it saves some text (~5k total in all network drivers)
> and removes a branch on rx path on non-VLAN enabled kernels...
DaveM beat me to it, but as he said, it saves 5K only if you have all
the drivers built in or loaded. And even if it saves 200 bytes in one
module, unless that module text was already less than 200 bytes into a
page, you've saved no memory -- a 4300 byte module takes 2 pages on x86,
as does a 4100 byte module.
The only savings is in instruction cache, and it would be better to
perhaps uninline vlan_hwaccel_receive_skb() or __vlan_hwaccel_rx() and
make vlan_tx_tag_present be
#if defined(CONFIG_VLAN_8021Q) || defined (CONFIG_VLAN_8021Q_MODULE)
#define vlan_tx_tag_present(__skb) \
(VLAN_TX_SKB_CB(__skb)->magic == VLAN_TX_COOKIE_MAGIC)
#else
#define vlan_tx_tag_present(x) 0
#endif
to get the cache savings on the hot paths without the ugliness.
> > Besides, if you're going to do this, you can get rid of the
> > spin_lock functions around it to, since they only protect tp->vlgrp in
> > this instance.
>
> Done.
>
> > Please don't apply this to typhoon.c
>
> Please comment on the below patch fragment, is it ok with you?
NAK. The #ifdefs are ugly, for no significant gain.
And you introduced a race condition when you moved the spin_locks. The
test for tp->vlgrp is no longer protected.
--
Dave Dillow <dave@thedillows.org>
next prev parent reply other threads:[~2006-04-11 13:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-07 13:28 [PATCH] deinline a few large functions in vlan code Denis Vlasenko
2006-04-07 20:25 ` David S. Miller
2006-04-10 5:28 ` Denis Vlasenko
2006-04-10 5:45 ` David S. Miller
2006-04-10 14:16 ` [PATCH] deinline a few large functions in vlan code v2 Denis Vlasenko
2006-04-10 14:31 ` Auke Kok
2006-04-10 15:26 ` Dave Dillow
2006-04-11 7:28 ` Denis Vlasenko
2006-04-11 8:02 ` David S. Miller
2006-04-11 9:49 ` Ingo Oeser
[not found] ` <200604111502.52302.vda@ilport.com.ua>
2006-04-11 13:17 ` Ingo Oeser
2006-04-12 19:32 ` [RFD][PATCH] typhoon and core sample for folding away VLAN stuff (was: Re: [PATCH] deinline a few large functions in vlan code v2) Ingo Oeser
2006-04-12 20:10 ` [RFD][PATCH] typhoon and core sample for folding away VLAN stuff Ben Greear
2006-04-12 20:23 ` Stephen Hemminger
2006-04-12 20:51 ` David S. Miller
2006-04-13 1:24 ` Dave Dillow
2006-04-13 8:38 ` Denis Vlasenko
2006-04-13 15:00 ` Dave Dillow
2006-04-11 13:59 ` Dave Dillow [this message]
2006-04-12 8:55 ` [PATCH] deinline a few large functions in vlan code v2 Denis Vlasenko
2006-04-12 17:18 ` Dave Dillow
2006-04-13 6:04 ` Denis Vlasenko
2006-04-13 14:59 ` Dave Dillow
2006-04-13 11:32 ` Ingo Oeser
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=1144763984.16193.9.camel@dillow.idleaire.com \
--to=dave@thedillows.org \
--cc=davem@davemloft.net \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vda@ilport.com.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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
all inboxes | Powered by JetHome®