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

Thomas Davis wrote:
> 
> 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?

If Cisco can't do a balanced hash, that doesn't mean the idea is bad,
it just means they implemented it poorly.  I would think that
something as simple as: src_ip_port % num_devices would give a
fairly even spread.  I'm sure you could get fancier and take other
fields (dst_ip_port) into account in your hash.
 

-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

  reply	other threads:[~2001-08-24 20:56 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
2001-08-24 20:59       ` Ben Greear [this message]
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=3B86C01E.850008A@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tadavis@lbl.gov \
    /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.