netdev - Re: [PATCH] bonding: add mark mode

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: <5384.1241209883@death.nxdomain.ibm.com>
Date:	Fri, 01 May 2009 13:31:23 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Neil Horman <nhorman@...driver.com>
cc:	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net
Subject: Re: [PATCH] bonding: add mark mode

Neil Horman <nhorman@...driver.com> wrote:

>> 	If I'm not misunderstanding the purpose of the mode, I think
>> it's etherchannel compatible (meaning that the switch has to be
>> configured), so I'm not sure why there would ever be a need to flood
>> packets to all ports.
>> 
>It entirely possible that there may be no need to flood frames, I was just
>asking the question.  And while it is possible that this might be etherchannel
>compatible (in fact I agree, it does look compatible), I can see uses for it
>beyond that (active-backup with traffic-class load balancing for example).

	For that last comment (active-backup), are you thinking in terms
of N active slaves and one backup?

>> 	I think this would be generally be better a special hash policy,
>> in which case both the etherchannel (balance-xor) and 802.3ad modes
>> could take advantage of it.  I'd hazard to guess that Andy thought about
>> that, too, so what was the impediment?
>
>I honestly don't know, although I will say that making a special hash mode for
>balance-xor seems a bit odd, since the implication there would be that output
>port was no longer chosen by an xor operation.

	Well, there are already three different hash algorithms that can
be selected, and if the only thing stopping this functionality as some
type of different slave selection gizmo is terminology, then I'm happy
to change the name of "xmit_hash_policy" to simply "xmit_policy" (in a
backwards compatible manner, of course) and slap this in as a new
policy.  Yah, balance-xor has "xor" in the name, but that can either be
documented around or, again, aliased as "balance-policy" or something.

	I see no reason the terminology should stand in the way of
setting things up The Right Way (which, in this discussion, revolves
around this type of new slave selection stuff working for the largest
reasonable set of modes, here, etherchannel and 802.3ad).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
--
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