All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Davis <tadavis@lbl.gov>
To: Ben Greear <greearb@candelatech.com>
Cc: Andi Kleen <ak@suse.de>, Bernhard Busch <bbusch@biochem.mpg.de>,
	linux-kernel@vger.kernel.org
Subject: Re: Poor Performance for ethernet bonding
Date: Fri, 24 Aug 2001 11:17:42 -0700	[thread overview]
Message-ID: <3B869A46.B1EF708A@lbl.gov> (raw)
In-Reply-To: <3B865882.24D57941@biochem.mpg.de.suse.lists.linux.kernel> <oupg0ahmv2a.fsf@pigdrop.muc.suse.de> <3B867096.3A1D7DE@candelatech.com>

Ben Greear wrote:
> 
> Couldn't the bonding code be made to distribute pkts to one interface or
> another based on a hash of the sending IP port or something?  Seems like that
> would fix the reordering problem for IP packets....  It wouldn't help for
> a single stream, but I'm guessing the real world problem involves many streams,
> which on average should hash such that the load is balanced...
> 

Cisco etherchannel does this, by XOR'ing the dest address with the
source address, AND'ing with # of interfaces (limiting you to a power of
2), and then using the number to determine what channel to use.

Now, you end up in a 4 way Etherchannel, all the traffic going down one
channel, and the none going down the other three.  Does that sound like
a balanced solution?

Most bonding problems are either the card driver is busted, the card is
busted (el-cheapo NE2000 PCI clones are really bad..) or the switch
can't handle it.  Most cheap, dumb switches break big time when using
Bonding with them.


-- 
------------------------+--------------------------------------------------
Thomas Davis		| ASG Cluster guy
tadavis@lbl.gov		| 
(510) 486-4524		| "80 nodes and chugging Captain!"

  parent reply	other threads:[~2001-08-24 18:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B865882.24D57941@biochem.mpg.de.suse.lists.linux.kernel>
2001-08-24 13:44 ` Poor Performance for ethernet bonding Andi Kleen
2001-08-24 15:19   ` Ben Greear
2001-08-24 15:22     ` Andi Kleen
2001-08-24 15:45       ` Ben Greear
2001-08-24 16:04         ` Andi Kleen
2001-08-27  7:40           ` Henning P. Schmiedehausen
2001-08-24 18:17     ` Thomas Davis [this message]
2001-08-24 20:59       ` Ben Greear
2001-08-25  7:04 Willy Tarreau
2001-08-25 18:23 ` Ben Greear
2001-08-26  7:59   ` willy tarreau
  -- strict thread matches above, loose matches on Subject: below --
2001-08-24 13:37 Bernhard Busch
2001-08-24 14:12 ` Sergey Ostrovsky
2001-08-24 14:33 ` Martin Josefsson
2001-08-24 15:16   ` Ben Greear

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=3B869A46.B1EF708A@lbl.gov \
    --to=tadavis@lbl.gov \
    --cc=ak@suse.de \
    --cc=bbusch@biochem.mpg.de \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@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 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.