From: Jay Vosburgh <fubar@us.ibm.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: "Oleg V. Ukhno" <olegu@yandex-team.ru>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
Date: Tue, 01 Mar 2011 18:56:18 -0800 [thread overview]
Message-ID: <413.1299034578@death> (raw)
In-Reply-To: <20110301152951.646451c6@nehalam>
Stephen Hemminger <shemminger@vyatta.com> wrote:
>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.
Hmm.
Yes, the number of special case knobs in bonding is getting
rather large, and there are one or two other proposals in the pipe
besides this one.
It would be handy to be able to do things like run ebtables
style rules against traffic going in and out of the bond. Right now
ebtables is pretty tightly coupled with the bridge, so we'd need to add
a whole new set of netfilter "bondtables" or something. Or add hooks
for ebtables outside of the bridge.
For this particular patch, the src-mac business could be handled
by a netfilter module. The round-robin hash policy part would probably
have to stay in bonding.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2011-03-02 2:56 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
2011-03-02 2:56 ` Jay Vosburgh [this message]
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=413.1299034578@death \
--to=fubar@us.ibm.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=olegu@yandex-team.ru \
--cc=shemminger@vyatta.com \
/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).