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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 03 Mar 2011 09:24:25 -0800
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Andy Gospodarek <andy@...yhouse.net>
cc:	Neil Horman <nhorman@...driver.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: bonding...

Andy Gospodarek <andy@...yhouse.net> wrote:

>On Thu, Mar 03, 2011 at 06:45:39AM -0500, Neil Horman wrote:
>> On Wed, Mar 02, 2011 at 09:49:10PM -0800, David Miller wrote:
>> > 
>> > Hey, if someone could step up and help with bonding maintainence
>> > in some tangible way, I'd really appreciate it.
>> > 
>> > Currently the situation is that many people work on bonding patches,
>> > and whilst I do try and wait for some ACKs to arrive, I am the person
>> > who has to sort out when changes are ready, decide to apply them, and
>> > poke for review when things fall through the cracks.
>> > 
>> > Sometimes patches go for weeks without ACKs, and in that situation
>> > I have to either try to understand the changes myself, or wait
>> > potentially forever for someone with bonding knowledge to take a
>> > good look at the patch and properly review it.
>> > 
>> > It was nearly 2 weeks before Oleg V. Ukhno's 802.3ad round-robin patch
>> > got looked at by anyone with bonding knowledge.  And it only happened
>> > because I got tired of seeing his poor patch rot in patchwork
>> > and had to explicitly asked for review the other day.
>> > 
>> > This is unacceptable, people are submitting multiple bonding patches
>> > every single day now.  It needs a clueful bonding person looking at
>> > these submissions on a constant basis.
>> > 
>> > This is a serious problem and is backlogging the netdev patch queue.
>> > 
>> > So if someone would become an active bonding patch-accumulator, and
>> > send me sets of patches that are ready to apply, I would really
>> > appreciate it.
>> > 
>> > Thanks.
>> I nominate gospo.  If he doesn't want to, I can do it
>> Neil
>> 
>
>I would be willing to do it, but my one of my goals would be to prevent
>some of the feature creep we are currently seeing with bonding (as Ben
>has suggested).  That doesn't mean I want to stop all new features, but
>at this point things are starting to get out of control. I suspect this
>is why Jay has struggled to keep up with the patches.

	My main problem keeping up at the moment is another demand on my
time that should run its course in a couple of weeks.  My time for
community activity is somewhat limited until then.

	As far as the features go, yes, I agree that things are getting
out of hand.  The two pending patches for special cases related to
802.3ad (Oleg's patch to permit round robining, the other to enable
spanning aggregators across switches), for example, are fine
functionality, but there really needs to be a better, generic, way to do
this sort of niche case activity without adding more knobs.

	I personally like Stephen's suggestion to hook bonding into a
netfilter gadget, similar to ebtables for bridge.  Done properly, such a
gadget should handle (or be extended to handle) the niche cases that
right now end up as new knobs in the driver.

>I would also want to look at a restructuring of the configuration.  The
>lines are starting to blur between some of the modes and output port
>selection for other modes and that needs to be cleared up.

	What did you have in mind here?

	-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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ