From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
To: Jay Vosburgh <fubar@us.ibm.com>, netdev@vger.kernel.org
Subject: Re: Packet capture and Bonding asymmetries
Date: Thu, 10 Jun 2010 13:10:12 +0100 [thread overview]
Message-ID: <20100610121012.GB11110@cel.leo> (raw)
In-Reply-To: <17501.1276123951@death.nxdomain.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]
On Wed, Jun 09, 2010 at 03:52:31PM -0700, Jay Vosburgh wrote:
> >I believe this should be fixable with a one-line patch; just adding a
> >call to netif_nit_deliver(skb) from within the bonding driver... though
> >just offhand I'm unable to find exactly the line where packets received
> >on slaves gets passed up to the master. :)
>
> This won't work, because bonding does not have a receive
> function in the usual sense. Instead, the slaves do their normal
> receive logic, and then in __netif_receive_skb, packets are assigned to
> the bonding master if the device is a slave.
Ah; that would explain why I'm having trouble finding it then :)
> For your own private testing, you could add a call to
> __netif_nit_deliver in netif_receive_skb prior to this part:
<snip>
Rather than put it -before- that part, why not inside the if (master)
arm?
-----
diff -urp linux-2.6.33.2.orig/net/core/dev.c linux-2.6.33.2/net/core/dev.c
--- linux-2.6.33.2.orig/net/core/dev.c 2010-04-02 00:02:33.000000000 +0100
+++ linux-2.6.33.2/net/core/dev.c 2010-06-10 12:58:24.000000000 +0100
@@ -2443,6 +2443,7 @@ int netif_receive_skb(struct sk_buff *sk
orig_dev = skb->dev;
master = ACCESS_ONCE(orig_dev->master);
if (master) {
+ netif_nit_deliver(skb);
if (skb_bond_should_drop(skb, master))
null_or_orig = orig_dev; /* deliver only exact match */
else
-----
(This patch doesn't quite apply cleanly to latest source but if that
approach seems OK I'll rebuild it and submit properly)
> This will give you multiple captures of the same packet, as is
> seen for transmit (i.e., one on the slave, one on the bond). For
> non-bonding devices, tcpdump will see each packet twice on the same
> device, so it's not really suitable for general use.
I was hoping for a proper permanent solution - often it would have been
useful to me, that eth0 appears to receive traffic properly to tcpdump
et.al., as well as transmitting.
> If merely knowing the traffic counts is sufficient, the slaves
> do count their received packets individually, so, e.g., ifconfig will
> show how many packets a particular slave has received, regardless of
> what bonding does with them. The packet counts for the bonding device
> itself are merely a sum of all of its slaves.
I had noticed the counters, yes. That has been useful on occasions. But
at other times we've really wanted to be able to see the actual traffic.
> Also, generally speaking, IP protocol traffic that arrives on an
> inactive bonding slave is not delivered. If you're using active-backup
> mode, and your traffic makes it through, it likely arrived on the active
> slave.
Useful though that is, sometimes it's the fact that traffic appears on a
non-active slave, which is interesting, and we'd like to see what
traffic that was.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2010-06-10 12:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 21:27 Packet capture and Bonding asymmetries Paul LeoNerd Evans
2010-06-09 22:52 ` Jay Vosburgh
2010-06-10 12:10 ` Paul LeoNerd Evans [this message]
2010-06-11 12:18 ` Paul LeoNerd Evans
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=20100610121012.GB11110@cel.leo \
--to=leonerd@leonerd.org.uk \
--cc=fubar@us.ibm.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).