From: Stephen Hemminger <shemminger@vyatta.com>
To: "Oleg V. Ukhno" <olegu@yandex-team.ru>
Cc: netdev@vger.kernel.org, Jay Vosburgh <fubar@us.ibm.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
Date: Tue, 1 Mar 2011 15:29:51 -0800 [thread overview]
Message-ID: <20110301152951.646451c6@nehalam> (raw)
In-Reply-To: <20110301223458.GA24403@yandex-team.ru>
On Wed, 2 Mar 2011 01:34:58 +0300
"Oleg V. Ukhno" <olegu@yandex-team.ru> wrote:
> Patch introduces two new (related) features to bonding module.
> First feature is round-robin hashing policy, which is primarily
> intended for use with 802.3ad mode, and puts every next IPv4 and
> IPv6 packet into next availables slave without taling into account
> which layer3 and above protocol is used.
> Second feature makes possible choosing which MAC-address will be set
> in the transmitted packet - when set to src-mac it will force setting
> slave's interface real MAC address as source MAC address in every
> packet, sent via this slave interface.
> Main goal of this patch is to make possible single TCP stream
> equally striped for both transmitted and received packets over all
> available slaves.
> This operating mode is not fully 802.3ad compliant, and will cause
> some packet reordering in TCP stream, to some kernel tuning may be
> required.
> For correct working enabling round-robin hashing policy plus using
> real slave's MAC addresses as source MAC addresses in transmitted
> packets requires specific switch setting)hashing mode for port-channel
> ("etherchannel) should be set to src-mac or src-dst-mac to get
> correct load-striping on the receiving host's etherchannel.
> General requirements for using bonding in this operating mode are:
> - even and preferrably equal number of slaves on sending and receiving
> hosts;
> - equal RTT between sending and receiving hosts on all slaves;
> - switch capable of doing etherchannels and using src-mac or src-dst-mac
> hashing policy for egress load striping
>
> Signed-off-by: Oleg V. Ukhno <olegu@yandex-team.ru>
It seems to me the whole bonding policy is getting so complex
that the code is a mess. Perhaps it should be somehow linked into
existing packet classification or firewall mechanisms. This would
increase the flexibility and reduce the amount of policy code
in the bonding driver itself.
--
next prev parent reply other threads:[~2011-03-01 23:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 22:34 [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode Oleg V. Ukhno
2011-03-01 23:29 ` Stephen Hemminger [this message]
2011-03-02 2:56 ` Jay Vosburgh
2011-03-02 9:15 ` Oleg V. Ukhno
-- strict thread matches above, loose matches on Subject: below --
2011-02-16 19:13 Oleg V. Ukhno
2011-02-28 0:08 ` David Miller
2011-02-28 10:09 ` Oleg V. Ukhno
2011-02-28 19:29 ` Jay Vosburgh
2011-03-01 22:38 ` Oleg V. Ukhno
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=20110301152951.646451c6@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=olegu@yandex-team.ru \
/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.