From: Florian Fainelli <f.fainelli@gmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, jiri@resnulli.us,
stephen@networkplumber.org, andy@greyhouse.net, tgraf@suug.ch,
nbd@openwrt.org, john.r.fastabend@intel.com, edumazet@google.com,
vyasevic@redhat.com, buytenh@wantstofly.org,
sfeldma@cumulusnetworks.com
Subject: HW bridging support using notifiers?
Date: Thu, 02 Oct 2014 18:48:57 -0700 [thread overview]
Message-ID: <542E0089.5050005@gmail.com> (raw)
Hi all,
I am taking a look at adding HW bridging support to DSA, in way that's
usable outside of DSA.
Lennert's approach in 2008 [1] looks conceptually good to me,as he
noted, it uses a bunch of new ndo's which is not only limiting to one
ndo implementer per struct net_device, but also is mostly consuming the
information from the bridge layer, while the ndo is an action
So here's what I am up to now:
- use the NETDEV_JOIN notifier to discover when a bridge port is added
- use the NETDEV_LEAVE notifier, still need to verify this does not
break netconsole as indicated in net/bridge/br_if.c
- use the NETDEV_CHANGEINFODATA notifier to notify about STP state changes
Now, this raises a bunch of questions:
- we would need a getter to return the stp state of a given network
device when called with NETDEV_CHANGEINFODATA, is that acceptable? This
would be the first function exported by the bridge layer to expose
internal data
NB: this also raises the question of the race condition and locking
within br_set_stp_state() and when the network devices notifier callback
runs
- or do we need a new network device notifier accepting an opaque
pointer which could provide us with the data we what, something like
this: call_netdevices_notifier_data(NETDEV_CHANGEINFODATA, dev, info),
where info would be a structure/union telling what's this data about
Let me know what you think, thanks!
[1]: http://patchwork.ozlabs.org/patch/16578/
--
Florian
next reply other threads:[~2014-10-03 1:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-03 1:48 Florian Fainelli [this message]
2014-10-03 5:13 ` HW bridging support using notifiers? Scott Feldman
2014-10-03 7:53 ` Jiri Pirko
2014-10-03 14:22 ` Benjamin LaHaise
2014-10-03 19:06 ` Florian Fainelli
2014-10-03 19:42 ` Benjamin LaHaise
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=542E0089.5050005@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andy@greyhouse.net \
--cc=buytenh@wantstofly.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=john.r.fastabend@intel.com \
--cc=nbd@openwrt.org \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@cumulusnetworks.com \
--cc=stephen@networkplumber.org \
--cc=tgraf@suug.ch \
--cc=vyasevic@redhat.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 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.