netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).