All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@openvz.org>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [RFC][PATCH] Turn part of SNMP accounting macros into functions
Date: Thu, 28 Aug 2008 15:12:39 +0400	[thread overview]
Message-ID: <48B68827.2060105@openvz.org> (raw)
In-Reply-To: <48B589B5.7050303@cosmosbay.com>

Eric Dumazet wrote:
> Pavel Emelyanov a écrit :
>> After turning IP_XXX_STATS, TCP_XXX_STATS and NET_XXX_STATS from
>> macros into functions the net/ipv4/built-in.o shrank significantly:
>>
>> add/remove: 14/0 grow/shrink: 0/67 up/down: 482/-2246 (-1764)
>>
>> Turning the CONFIG_NET_NS option on makes this shrink even larger:
>>
>> add/remove: 14/0 grow/shrink: 0/67 up/down: 478/-2646 (-2168)
>>
>> So the question is - what was the reason to keep those as macros?
>> I thought about the possible performance questions, but netperf
>> didn't show any (I admit I just cannot cook it properly).
>>
>> The sample patch is here, but it's not good (EXPORTs for ipv6
>> and a better place for functions rather than net/ipv4/af_inet.c
>> are required).
>>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>>
> 
> 
> I dont know, but passing all those "struct net *net" to every 
> network function in the kernel sounds overkill, especially for
> !CONFIG_NET_NS users. This is pure bloat.
> 
> We could define two macros so that function prototypes dont include
> useless pointers, especially on arches where only first and second
> parameter is passed in eax and edx register ;)
> 
> #ifdef CONFIG_NET_NS
> # define VNETPTR ,struct net *net
> # define NETPTR  net
> #else
> # define VNETPTR
> # defint NETPTR  &init_net
> #endif
> 
> ...
> void TCP_DEC_STATS(int field VNETPTR);
> ...
> void TCP_DEC_STATS(int field VNETPTR)
> {
> 	SNMP_DEC_STATS((NETPTR)->mib.tcp_statistics, field);
> }
> ...

I agree with this, but I've checked whether compiling out the first argument
of XXX_STATS would help and found out that there's almost no difference (-9
bytes) in the net/ipv4/built-in.o for NET_NS=n case. 

After turning the macros into functions, compiling the first argument out gives
us 500 more bytes out. Good catch, but I have a question - the way you proposed
to implement the function itself is rather nice, but how would you implement
the *call* to that function in order to make it variable-arguments depending on
the config option?

I see the similar way:

+#ifdef CONFIG_NET_NS
+#define NET_ARG(net) net,
+#else
+#define NET_ARG(net)
+#endif
...
-	TCP_INC_STATS(sock_net(sk), field);
+	TCP_INC_STATS(NET_ARG(sock_net(sk) field);

but do these 500 bytes compensate for this ugly style?

  reply	other threads:[~2008-08-28 11:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-27 16:31 [RFC][PATCH] Turn part of SNMP accounting macros into functions Pavel Emelyanov
2008-08-27 16:41 ` Stephen Hemminger
2008-08-27 16:56 ` Ilpo Järvinen
2008-08-27 17:09   ` Pavel Emelyanov
2008-08-27 17:58     ` Ilpo Järvinen
2008-08-27 17:07 ` Eric Dumazet
2008-08-28 11:12   ` Pavel Emelyanov [this message]
2008-08-28 12:51     ` Eric Dumazet
2008-08-28 12:54       ` Pavel Emelyanov
2008-08-29  7:01 ` Herbert Xu
2008-08-29  7:29   ` Pavel Emelyanov
2008-08-29 12:57   ` Christoph Lameter

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=48B68827.2060105@openvz.org \
    --to=xemul@openvz.org \
    --cc=dada1@cosmosbay.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.