From: Tobias Waldekranz <tobias@waldekranz.com>
To: netdev@vger.kernel.org
Subject: Deliver skbs to intermediate interfaces, when using cascaded rx-handlers
Date: Fri, 21 Feb 2014 11:01:58 +0100 [thread overview]
Message-ID: <20140221100158.GA19594@gmail.com> (raw)
I have a system with the following configuration:
* eth0 is a regular Ethernet MAC, connected to a hardware switch.
* port[1-4] are the in-kernel representation of the switch.
* team0 is a regular team-interface which bonds port1 and port2.
+-------+
| team0 |
+---+---+
|
+----+----+
| |
+---+---+ +---+---+ +-------+ +-------+
| port1 | | port2 | | port3 | | port4 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
+---------+----+----+---------+
|
+---+---+
| eth0 |
+-------+
Both the switch and the team driver attaches rx-handlers to their
lower layers. The problem is that team expects LACP frames that
are intercepted by team0, to also be delivered to the port interface
by __netif_receive_skb_core (in the final iteration of the registered
protocols). However in this case, when two rx-handlers are cascaded,
the skb will be delivered to eth0, since that is the original device
(orig_dev).
There are a few ways this can be solved as far as i can see:
1. Introduce a new rx-handler return code that specifies that
skb->dev has been altered, like RX_HANDLER_ANOTHER, and that we
also want to change orig_dev to this new device.
2. Change the switch driver to return RX_HANDLER_CONSUMED and then
queue the skb all over again, though I am afraid that this will eat
some cycles.
3. Keep track of all traversed interfaces and change the final
protocol iteration to deliver the skb to all intermediate devices.
What would be your suggestion?
--
Thanks
- wkz
next reply other threads:[~2014-02-21 10:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-21 10:01 Tobias Waldekranz [this message]
2014-02-21 10:26 ` Deliver skbs to intermediate interfaces, when using cascaded rx-handlers Jiri Pirko
2014-02-21 11:12 ` Tobias Waldekranz
2014-02-21 11:37 ` Jiri Pirko
2014-02-21 12:02 ` Tobias Waldekranz
2014-02-21 13:05 ` Jiri Pirko
2014-02-21 14:31 ` Tobias Waldekranz
2014-02-21 14:48 ` Jiri Pirko
2014-02-21 14:54 ` Tobias Waldekranz
2014-02-21 17:23 ` David Miller
2014-02-24 7:28 ` Tobias Waldekranz
2014-02-21 17:10 ` Flavio Leitner
2014-02-24 7:22 ` Tobias Waldekranz
2014-02-26 18:18 ` Flavio Leitner
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=20140221100158.GA19594@gmail.com \
--to=tobias@waldekranz.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 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).