From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: Jay Vosburgh <fubar@us.ibm.com>,
David Miller <davem@davemloft.net>,
kaber@trash.net, eric.dumazet@gmail.com, netdev@vger.kernel.org,
shemminger@linux-foundation.org, andy@greyhouse.net, "Fischer,
Anna" <anna.fischer@hp.com>
Subject: Re: [patch net-next-2.6 V3] net: convert bonding to use rx_handler
Date: Tue, 22 Feb 2011 00:20:04 +0100 [thread overview]
Message-ID: <4D62F324.6020301@gmail.com> (raw)
In-Reply-To: <20110220150710.GB2750@psychotron.redhat.com>
Le 20/02/2011 16:07, Jiri Pirko a écrit :
> Sun, Feb 20, 2011 at 01:12:01PM CET, nicolas.2p.debian@gmail.com wrote:
[snip]
>> And thinking about all this, I wonder what the protocol handlers expect as the orig_dev value ?
>>
>> Lets imagine the following configuration: eth0 -> bond0 -> br0.
>>
>> What does a protocol handler listening on br0 expect for orig_dev ?
>> bond0 or eth0 ? Current implementation give eth0, but I think bond0
>> should be the right value, for proper nesting.
>
> I agree with you.
[snip}
>>> This hook is something I do not like at all :/ But anyway if should be in vlan
>>> part I think.
>>
>> Yes, and in order for the future rx_handler for vlan to properly
>> handle it, it needs to know the device just below it, not the pure
>> original device. Hence, my question about the exact meaning of
>> orig_dev...
After checking every protocol handlers installed by dev_add_pack(), it appears that only 4 of them
really use the orig_dev parameter given by __netif_receive_skb():
- bond_3ad_lacpdu_recv() @ drivers/net/bonding/bond_3ad.c
- bond_arp_recv() @ drivers/net/bonding/bond_main.c
- packet_rcv() @ net/packet/af_packet.c
- tpacket_rcv() @ net/packet/af_packet.c
From the bonding point of view, the meaning of orig_dev is obviously "the device one layer below
the bonding device, through which the packet reached the bonding device". It is used by
bond_3ad_lacpdu_recv() and bond_arp_recv(), to find the underlying slave device through which the
LACPDU or ARP was received. (The protocol handler is registered at the bonding device level).
From the af_packet point of view, the meaning is documented (in commit "[AF_PACKET]: Add option to
return orig_dev to userspace") as the "physical device [that] actually received the traffic, instead
of having the encapsulating device hide that information."
When the bonding device is just one level above the physical device, the two meanings happen to
match the same device, by chance.
So, currently, a bonding device cannot stack properly on top of anything but physical devices. It
might not be a problem today, but may change in the future...
Nicolas.
next prev parent reply other threads:[~2011-02-21 23:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 13:25 [patch net-next-2.6] net: convert bonding to use rx_handler Jiri Pirko
2011-02-18 13:29 ` Eric Dumazet
2011-02-18 14:14 ` Jiri Pirko
2011-02-18 14:27 ` Eric Dumazet
2011-02-18 14:46 ` Patrick McHardy
2011-02-18 14:58 ` Jiri Pirko
2011-02-18 15:50 ` Patrick McHardy
2011-02-18 16:14 ` Eric Dumazet
2011-02-18 18:47 ` Jiri Pirko
2011-02-18 19:17 ` Eric Dumazet
2011-02-18 19:28 ` Jiri Pirko
2011-02-18 19:58 ` Eric Dumazet
2011-02-18 20:03 ` Jiri Pirko
2011-02-18 20:06 ` David Miller
2011-02-18 20:13 ` Jiri Pirko
2011-02-18 20:58 ` [patch net-next-2.6 V2] " Jiri Pirko
2011-02-18 23:06 ` Jay Vosburgh
2011-02-19 7:44 ` Jiri Pirko
2011-02-19 8:05 ` [patch net-next-2.6 V3] " Jiri Pirko
2011-02-19 8:37 ` Eric Dumazet
2011-02-19 8:58 ` Jiri Pirko
2011-02-19 9:22 ` Eric Dumazet
2011-02-19 10:56 ` Nicolas de Pesloüan
2011-02-19 11:08 ` Jiri Pirko
2011-02-19 11:28 ` Jiri Pirko
2011-02-19 13:18 ` Nicolas de Pesloüan
2011-02-19 13:46 ` Jiri Pirko
2011-02-19 14:32 ` Nicolas de Pesloüan
2011-02-19 20:27 ` Nicolas de Pesloüan
2011-02-20 10:36 ` Jiri Pirko
2011-02-20 12:12 ` Nicolas de Pesloüan
2011-02-20 15:07 ` Jiri Pirko
2011-02-21 23:20 ` Nicolas de Pesloüan [this message]
2011-02-26 14:24 ` Nicolas de Pesloüan
2011-02-26 19:42 ` Jay Vosburgh
2011-02-27 12:58 ` Jiri Pirko
2011-02-27 20:44 ` Nicolas de Pesloüan
2011-02-27 23:22 ` David Miller
2011-02-28 7:07 ` Jiri Pirko
2011-02-28 7:30 ` David Miller
2011-02-28 9:22 ` Jiri Pirko
2011-02-28 9:35 ` Eric Dumazet
2011-02-28 9:55 ` [patch net-next-2.6] net: convert bonding to use rx_handler - second part Jiri Pirko
2011-02-28 18:49 ` [patch net-next-2.6 V3] net: convert bonding to use rx_handler David Miller
2011-02-23 19:05 ` Jiri Pirko
2011-02-25 23:46 ` Nicolas de Pesloüan
2011-02-26 7:14 ` Jiri Pirko
2011-02-26 11:25 ` Nicolas de Pesloüan
2011-02-26 14:58 ` Jiri Pirko
2011-02-27 14:17 ` Nicolas de Pesloüan
2011-02-27 20:06 ` Jiri Pirko
2011-02-27 20:59 ` Nicolas de Pesloüan
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=4D62F324.6020301@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=anna.fischer@hp.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fubar@us.ibm.com \
--cc=jpirko@redhat.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.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 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).