From: Arvid Brodin <arvid.brodin@enea•com>
To: Jay Vosburgh <fubar@us•ibm.com>
Cc: Stephen Hemminger <shemminger@vyatta•com>, <netdev@vger•kernel.org>
Subject: Re: bridge: HSR support
Date: Thu, 8 Dec 2011 15:45:37 +0100 [thread overview]
Message-ID: <4EE0CD91.2070804@enea.com> (raw)
In-Reply-To: <14653.1323287989@death>
Jay Vosburgh wrote:
> Arvid Brodin <arvid.brodin@enea•com> wrote:
>> * I don't know the meaning of the IFF_SLAVE flag. It's referenced all over the place
>> (core, vlan, bonding, ipv6, eql). Do I need to/want to set this?
>
> Only if you actually need to for some reason. There are a few
> tests that make actual use of IFF_SLAVE, e.g., IPv6 won't run addrconf
> on an interface with IFF_SLAVE set (which prevents bonding slaves from
> having an IPv6 address distinct from the master). Netpoll also treats
> interfaces with IFF_SLAVE in a special way. Bonding uses it internally
> for various tests.
>
>> * I don't know the effects of setting dev->master. Do I need/want this?
>
> Maybe. One effect of netdev_set_master is that a reference is
> acquired on the master, on behalf of the slave, so the master cannot
> simply vanish until the slave releases that reference. This predates
> the notifier facility, and careful use of notifiers (handling
> NETDEV_UNREGISTER) can get around the need for dev->master, but, e.g.,
> vlan still acquires a reference to the real_dev without using
> dev->master.
>
> It used to be that dev->master was used in netif_receive_skb for
> packet handling purposes (for bonding, mostly; bridge and I think
> macvlan had separate hooks). That special sauce is now done by the
> rx_handler, so there's really no requirement to use dev->master if you
> have no need.
>
>> * I don't want to forward all ingress frames on the slave devices to my master
>> device; I only want the ones with protocol 0x88FB to be forwarded (other
>> frames should be received by the slaves as normal). I think I already have this
>> covered by registering a protocol handler (using dev_add_pack(packet_type)).
>> So perhaps calling netdev_rx_handler_register() is not necessary in my case?
>
> You may want to use the rx_handler, and have it set skb->dev
> appropriately for the frames that should forward to the master, and
> leave skb->dev alone for the ones that should stick with the slave.
> Both of those need the appropriate return from the rx_handler, which is
> documented in netdevice.h.
>
> I'm not sure that you need a dev_add_pack at all; bonding
> doesn't use one anymore, since everything it needs can now be done via
> rx_handler. The dev_add_pack approach may work, but rx_handler is
> probably more efficient.
>
>> * As far as I can see, neither bridging nor bonding is handled by the ip program
>> (iproute2 suite)? I.e. no examples of binding more than one interface to a
>> virtual interface when it comes to which messages to send, etc. VLAN uses
>> IFLA_IFNAME (name of the vlan link), IFLA_LINK (physical link behind the vlan
>> link), and some IFLA_VLAN-specific messages.
>
> In current versions of iproute, something like "ip link set
> device eth0 master bond0" would add a slave to a bond. You are correct,
> though, that ip does not permit changing the bonding options, and I
> don't believe it will create new master devices, either, so the bonding
> support is limited.
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us•ibm.com
>
Lots of great info there, many thanks!
--
Arvid Brodin
Enea Services Stockholm AB
next prev parent reply other threads:[~2011-12-08 14:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E948A04.8060400@enea.com>
[not found] ` <20111011112821.28cd3e51@nehalam.linuxnetplumber.net>
2011-10-11 23:51 ` bridge: HSR support Arvid Brodin
2011-10-12 13:28 ` David Lamparter
2011-10-12 14:24 ` Arvid Brodin
2011-10-24 14:17 ` Arvid Brodin
2011-10-28 15:34 ` Arvid Brodin
2011-10-28 15:54 ` Stephen Hemminger
2011-10-28 16:36 ` Arvid Brodin
2011-12-06 23:23 ` Arvid Brodin
2011-12-06 23:27 ` Stephen Hemminger
2011-12-07 18:30 ` Arvid Brodin
2011-12-07 19:59 ` Jay Vosburgh
2011-12-08 14:45 ` Arvid Brodin [this message]
2011-11-21 16:52 ` Arvid Brodin
2012-01-06 18:11 ` Arvid Brodin
2012-01-12 18:02 ` bridge: HSR support - possible recursive locking? Arvid Brodin
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=4EE0CD91.2070804@enea.com \
--to=arvid.brodin@enea$(echo .)com \
--cc=fubar@us$(echo .)ibm.com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/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