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: <20090501203900.GC5840@hmsreliant.think-freely.org>
Date:	Fri, 1 May 2009 16:39:00 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net
Subject: Re: [PATCH] bonding: add mark mode

On Fri, May 01, 2009 at 01:31:23PM -0700, Jay Vosburgh wrote:
> 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 suppose.  I really didn't have anything specific in mind, I was just musing on
what potential this might have.  As Andy mentioned in his post, this could be
used as an active backup mode where the backup links can still carry traffic.

> >> 	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).
> 
I'll stay out of your way and let you and Andy hash out "The Right Way" :).  I
just like the idea of being able to select your output destination :)

Neil

--
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