From: Jiri Pirko <jiri@resnulli.us>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
fubar@us.ibm.com, andy@greyhouse.net, kaber@trash.net,
stephen@networkplumber.org, jesse@nicira.com,
alexander.h.duyck@intel.com, xiyou.wangcong@gmail.com,
dev@openvswitch.org, rostedt@goodmis.org,
nicolas.2p.debian@gmail.com, tglx@linutronix.de,
streeter@redhat.com, paulmck@us.ibm.com, ivecera@redhat.com
Subject: Re: [patch net-next] net: squash ->rx_handler and ->rx_handler_data into single rcu pointer
Date: Sat, 30 Mar 2013 18:13:25 +0100 [thread overview]
Message-ID: <20130330171325.GC1544@minipsycho.orion> (raw)
In-Reply-To: <1364660588.5113.110.camel@edumazet-glaptop>
Sat, Mar 30, 2013 at 05:23:08PM CET, eric.dumazet@gmail.com wrote:
>On Sat, 2013-03-30 at 16:57 +0100, Jiri Pirko wrote:
>> No need to have two pointers in struct netdevice for rx_handler func and
>> priv data. Just embed rx_handler structure into driver port_priv and
>> have ->func pointer there. This introduces no performance penalty,
>> reduces struct netdevice by one pointer and reduces number of needed
>> rcu_dereference calls from 2 to 1.
>>
>
>Thats not true.
>
>> Note this also fixes the race bug pointed out by Steven Rostedt and
>> fixed by patch "[PATCH] net: add a synchronize_net() in
>> netdev_rx_handler_unregister()" by Eric Dumazet. This is based on
>> current net-next tree where the patch is not applied yet.
>> I can rebase it on whatever tree/state, just say so.
>>
>> Smoke tested with all drivers who use rx_handler.
>>
>> Reported-by: Steven Rostedt <rostedt@goodmis.org>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>
>I see no value for this patch.
>
>It obfuscates things for no good reason.
Well, I like this what you call obfuscation. It looks similar to
list_head and rcu_head. I do not think that this makes the readibility
more difficult.
>
>Once again rcu_dereference(dev->field) has no cost, its a memory read,
>like dev->field.
Well, not entirely true, depends on arch.
>
>I fear you don't understand enough RCU to make so invasive changes.
>
>Your patch adds a double dereference on fast path, and its more
>expensive than two single deref.
>
>dev->rx_handler actually gets the function pointer, and after your patch
>we would have to do dev->rx_handler->func instead, which is bad on many
>cpus.
dev->rx_handler == port_priv and it is treated as such and accessed in
handle_frame driver functions. Is it really that bad to access deref
port_priv->pointer (rx_handler->func) couple of instructions earlier?
I wonder what the difference is in compare with the original code.
Thanks, Jiri
>
>I'll send a patch reordering some fields of net_device, because as time
>passed, it seems a lot of junk broke work done in commit
>cd13539b8bc9ae884 (net: shrinks struct net_device)
>
>offsetof(struct net_device,dev_addr)=0x258
>offsetof(struct net_device,rx_handler)=0x2b8
>offsetof(struct net_device,ingress_queue)=0x2c8
>offsetof(struct net_device,broadcast)=0x278
>
>
next prev parent reply other threads:[~2013-03-30 17:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-30 15:57 [patch net-next] net: squash ->rx_handler and ->rx_handler_data into single rcu pointer Jiri Pirko
[not found] ` <1364659034-7049-1-git-send-email-jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
2013-03-30 16:23 ` Eric Dumazet
2013-03-30 17:13 ` Jiri Pirko [this message]
[not found] ` <20130330171325.GC1544-RDzucLLXGGI88b5SBfVpbw@public.gmane.org>
2013-03-30 19:28 ` Eric Dumazet
2013-03-30 19:31 ` Eric Dumazet
2013-03-30 19:32 ` Eric Dumazet
2013-03-30 19:24 ` Steven Rostedt
[not found] ` <f72ccc9e-b09e-4abb-a0ce-a6516138b25c-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2013-03-30 19:32 ` Jiri Pirko
[not found] ` <20130330193210.GD1544-RDzucLLXGGI88b5SBfVpbw@public.gmane.org>
2013-04-08 16:32 ` Steven Rostedt
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=20130330171325.GC1544@minipsycho.orion \
--to=jiri@resnulli.us \
--cc=alexander.h.duyck@intel.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=fubar@us.ibm.com \
--cc=ivecera@redhat.com \
--cc=jesse@nicira.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=nicolas.2p.debian@gmail.com \
--cc=paulmck@us.ibm.com \
--cc=rostedt@goodmis.org \
--cc=stephen@networkplumber.org \
--cc=streeter@redhat.com \
--cc=tglx@linutronix.de \
--cc=xiyou.wangcong@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).