netdev - Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D4833EA.50407@yandex-team.ru>
Date:	Tue, 01 Feb 2011 19:25:14 +0300
From:	"Oleg V. Ukhno" <olegu@...dex-team.ru>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for
 single TCP session balancing

On 01/29/2011 05:28 AM, Jay Vosburgh wrote:
> Oleg V. Ukhno<olegu@...dex-team.ru>  wrote:
>
> 	I've thought about this whole thing, and here's what I view as
> the proper way to do this.
>
> 	In my mind, this proposal is two separate pieces:
>
> 	First, a piece to make round-robin a selectable hash for
> xmit_hash_policy.  The documentation for this should follow the pattern
> of the "layer3+4" hash policy, in particular noting that the new
> algorithm violates the 802.3ad standard in exciting ways, will result in
> out of order delivery, and that other 802.3ad implementations may or may
> not tolerate this.
>
> 	Second, a piece to make certain transmitted packets use the
> source MAC of the sending slave instead of the bond's MAC.  This should
> be a separate option from the round-robin hash policy.  I'd call it
> something like "mac_select" with two values: "default" (what we do now)
> and "slave_src_mac" to use the slave's real MAC for certain types of
> traffic (I'm open to better names; that's just what I came up with while
> writing this).  I believe that "certain types" means "everything but
> ARP," but might be "only IP and IPv6."  Structuring the option in this
> manner leaves the option open for additional selections in the future,
> which a simple "on/off" option wouldn't.  This option should probably
> only affect a subset of modes; I'm thinking anything except balance-tlb
> or -alb (because they do funky MAC things already) and active-backup (it
> doesn't balance traffic, and already uses fail_over_mac to control
> this).  I think this option also needs a whole new section down in the
> bottom explaining how to exploit it (the "pick special MACs on slaves to
> trick switch hash" business).
>
> 	Comments?
>
> 	-J
>
Jay,
As for me splitting my initial proposal into two logically diffent 
pieces is ok, this will provide more flexible configuration.
Do I understand correctly, that after I rewrite  patch in splitted form, 
as you described above, and enhance documentation it will be /can be 
applied to kernel?
Then what should I do: rewrite patch and resubmit it as a new one?

Oleg.

> ---
> 	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
>


-- 
Best regards,
Oleg Ukhno.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html