Bonding

Bonding

[Gustavo Pimentel]

Hi,

I'm writing you because because I'm have implemented a new mode (PRP Parallel Redundancy Protocol) for bonding kernel driver. This new mode is quite simple, I don't know if you have heard about PRP, but it's a new standard that allows to overcome any single network failure without affecting the data transmission. The general idea resides on having two separate LAN (A & B) very similar and transmitting the almost the same frame through both LANs and the end device should accept one frame and discard the other according to a known mechanism. 

I have implemented this new mode on bonding driver, but I have some difficulties:
. Writing linux driver is quite new for me. I don't' know if exists guide lines for driver coding.
. I don't know how to submit the code to be include on kernel repository.
. Maybe another pair of eyes could find help to improve the writing code for this mode.

I think my driver code is 99% complete. I'm currently testing with 3 equipments (1 pc + 1 embedded device running both my modify bonding driver) and a third party equipment called RedBox.

Would you be interested in participating / helping this project?

With my best regards, 

Gustavo Gama da Rocha Pimentel
Power Systems Automation / Innovation & Development
Efacec Engenharia e Sistemas, S.A.
Phone: +351229403391
Disclaimer

Re: Bonding

[Veaceslav Falico]

On Tue, Feb 11, 2014 at 01:53:32PM +0000, Gustavo Pimentel wrote:
>Hi,

Hi Gustavo,

>
>I'm writing you because because I'm have implemented a new mode (PRP Parallel Redundancy Protocol) for bonding kernel driver. This new mode is quite simple, I don't know if you have heard about PRP, but it's a new standard that allows to overcome any single network failure without affecting the data transmission. The general idea resides on having two separate LAN (A & B) very similar and transmitting the almost the same frame through both LANs and the end device should accept one frame and discard the other according to a known mechanism.

Isn't that the current 'broadcast' mode, where every packet is transmitted
over all the slaves? After quick googling/reading I don't see any
difference there, though I might have missed something.

>
>I have implemented this new mode on bonding driver, but I have some difficulties:
>. Writing linux driver is quite new for me. I don't' know if exists guide lines for driver coding.

You can find everything under Documentation/, but without the code I can't
tell you exact documents. CodingStyle and SubmittingPatches might be the
first ones.

Also, try CC-ing relevant people for more feedback, specifically bonding
maintainers.

>. I don't know how to submit the code to be include on kernel repository.
>. Maybe another pair of eyes could find help to improve the writing code for this mode.

Try sending an RFC when net-next opens.

>
>I think my driver code is 99% complete. I'm currently testing with 3 equipments (1 pc + 1 embedded device running both my modify bonding driver) and a third party equipment called RedBox.
>
>Would you be interested in participating / helping this project?
>
>With my best regards,
>
>Gustavo Gama da Rocha Pimentel
>Power Systems Automation / Innovation & Development
>Efacec Engenharia e Sistemas, S.A.
>Phone: +351229403391
>Disclaimer
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Bonding

[Gustavo Pimentel]

Hi Veaceslav,

It's quite different from broadcast mode, each frame sent through the slaves has attached a Redundancy Control Trailer also known as RCT (this trailer is compose by a LAN identifier, sequence number, a LSDU size and a PRP suffix).
Also the equipment with PRP capability has to send periodically a supervision frame to both similar LANs. Each device on the network has to keep track of receive sequence numbers received, if the received a sequence number for instance from LAN A of specific device and it doesn't exist on internal table, the device should accept the frame and update the internal table. When receiving the same sequence number from the LAN B, the device should discard it, providing zero downtime redundancy.

I can supply you information about this redundancy protocol, if you like. This type of network redundancy is now being large deployed on electrical power stations (like thermal and hydro) and transmission power stations instead of teaming / bonding that depends on RSTP for redundancy.

> -----Original Message-----
> From: Veaceslav Falico [mailto:vfalico@redhat.com]
> Sent: terça-feira, 11 de Fevereiro de 2014 14:16
> To: Gustavo Pimentel
> Cc: netdev@vger.kernel.org
> Subject: Re: Bonding
> 
> On Tue, Feb 11, 2014 at 01:53:32PM +0000, Gustavo Pimentel wrote:
> >Hi,
> 
> Hi Gustavo,
> 
> >
> >I'm writing you because because I'm have implemented a new mode (PRP Parallel
> Redundancy Protocol) for bonding kernel driver. This new mode is quite simple, I
> don't know if you have heard about PRP, but it's a new standard that allows to
> overcome any single network failure without affecting the data transmission. The
> general idea resides on having two separate LAN (A & B) very similar and
> transmitting the almost the same frame through both LANs and the end device
> should accept one frame and discard the other according to a known mechanism.
> 
> Isn't that the current 'broadcast' mode, where every packet is transmitted over all
> the slaves? After quick googling/reading I don't see any difference there, though I
> might have missed something.
> 
> >
> >I have implemented this new mode on bonding driver, but I have some
> difficulties:
> >. Writing linux driver is quite new for me. I don't' know if exists guide lines for
> driver coding.
> 
> You can find everything under Documentation/, but without the code I can't tell you
> exact documents. CodingStyle and SubmittingPatches might be the first ones.
> 
> Also, try CC-ing relevant people for more feedback, specifically bonding
> maintainers.
> 
> >. I don't know how to submit the code to be include on kernel repository.
> >. Maybe another pair of eyes could find help to improve the writing code for this
> mode.
> 
> Try sending an RFC when net-next opens.
> 
> >
> >I think my driver code is 99% complete. I'm currently testing with 3 equipments (1
> pc + 1 embedded device running both my modify bonding driver) and a third party
> equipment called RedBox.
> >
> >Would you be interested in participating / helping this project?
> >
> >With my best regards,
> >
> >Gustavo Gama da Rocha Pimentel
> >Power Systems Automation / Innovation & Development Efacec Engenharia e
> >Sistemas, S.A.
> >Phone: +351229403391
> >Disclaimer
> >
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org More majordomo info
> >at  http://vger.kernel.org/majordomo-info.html

Re: Bonding

[Jay Vosburgh]

Gustavo Pimentel <gustavo.pimentel@efacec.com> wrote:

>Hi Veaceslav,
>
>It's quite different from broadcast mode, each frame sent through the slaves has attached a Redundancy Control Trailer also known as RCT (this trailer is compose by a LAN identifier, sequence number, a LSDU size and a PRP suffix).
>Also the equipment with PRP capability has to send periodically a supervision frame to both similar LANs. Each device on the network has to keep track of receive sequence numbers received, if the received a sequence number for instance from LAN A of specific device and it doesn't exist on internal table, the device should accept the frame and update the internal table. When receiving the same sequence number from the LAN B, the device should discard it, providing zero downtime redundancy.
>
>I can supply you information about this redundancy protocol, if you like. This type of network redundancy is now being large deployed on electrical power stations (like thermal and hydro) and transmission power stations instead of teaming / bonding that depends on RSTP for redundancy.

	Are you aware that there is already an implementation of HSR
(High-availability Seamless Redundancy) in the linux kernel?  I believe
HSR and PRP are defined by the same standard (IEC 62439-3), and are
similar enough to interoperate to some degree.  Perhaps PRP would be
better implemented as a variant within the existing net/hsr/ framework.

	-J


>> -----Original Message-----
>> From: Veaceslav Falico [mailto:vfalico@redhat.com]
>> Sent: terça-feira, 11 de Fevereiro de 2014 14:16
>> To: Gustavo Pimentel
>> Cc: netdev@vger.kernel.org
>> Subject: Re: Bonding
>> 
>> On Tue, Feb 11, 2014 at 01:53:32PM +0000, Gustavo Pimentel wrote:
>> >Hi,
>> 
>> Hi Gustavo,
>> 
>> >
>> >I'm writing you because because I'm have implemented a new mode (PRP Parallel
>> Redundancy Protocol) for bonding kernel driver. This new mode is quite simple, I
>> don't know if you have heard about PRP, but it's a new standard that allows to
>> overcome any single network failure without affecting the data transmission. The
>> general idea resides on having two separate LAN (A & B) very similar and
>> transmitting the almost the same frame through both LANs and the end device
>> should accept one frame and discard the other according to a known mechanism.
>> 
>> Isn't that the current 'broadcast' mode, where every packet is transmitted over all
>> the slaves? After quick googling/reading I don't see any difference there, though I
>> might have missed something.
>> 
>> >
>> >I have implemented this new mode on bonding driver, but I have some
>> difficulties:
>> >. Writing linux driver is quite new for me. I don't' know if exists guide lines for
>> driver coding.
>> 
>> You can find everything under Documentation/, but without the code I can't tell you
>> exact documents. CodingStyle and SubmittingPatches might be the first ones.
>> 
>> Also, try CC-ing relevant people for more feedback, specifically bonding
>> maintainers.
>> 
>> >. I don't know how to submit the code to be include on kernel repository.
>> >. Maybe another pair of eyes could find help to improve the writing code for this
>> mode.
>> 
>> Try sending an RFC when net-next opens.
>> 
>> >
>> >I think my driver code is 99% complete. I'm currently testing with 3 equipments (1
>> pc + 1 embedded device running both my modify bonding driver) and a third party
>> equipment called RedBox.
>> >
>> >Would you be interested in participating / helping this project?
>> >
>> >With my best regards,
>> >
>> >Gustavo Gama da Rocha Pimentel
>> >Power Systems Automation / Innovation & Development Efacec Engenharia e
>> >Sistemas, S.A.
>> >Phone: +351229403391
>> >Disclaimer

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

RE: Bonding

[Gustavo Pimentel]

Hi Jay,

I was not aware of that. You are correct, both HSR and PRP are defined on IEC 62439-3. I will try to contact the person in charge of HSR, to acquire more information about his driver status.


> -----Original Message-----
> From: Jay Vosburgh [mailto:fubar@us.ibm.com]
> Sent: terça-feira, 11 de Fevereiro de 2014 17:56
> To: Gustavo Pimentel
> Cc: Veaceslav Falico; netdev@vger.kernel.org
> Subject: Re: Bonding
> 
> Gustavo Pimentel <gustavo.pimentel@efacec.com> wrote:
> 
> >Hi Veaceslav,
> >
> >It's quite different from broadcast mode, each frame sent through the slaves has
> attached a Redundancy Control Trailer also known as RCT (this trailer is compose
> by a LAN identifier, sequence number, a LSDU size and a PRP suffix).
> >Also the equipment with PRP capability has to send periodically a supervision
> frame to both similar LANs. Each device on the network has to keep track of
> receive sequence numbers received, if the received a sequence number for
> instance from LAN A of specific device and it doesn't exist on internal table, the
> device should accept the frame and update the internal table. When receiving the
> same sequence number from the LAN B, the device should discard it, providing
> zero downtime redundancy.
> >
> >I can supply you information about this redundancy protocol, if you like. This
> type of network redundancy is now being large deployed on electrical power
> stations (like thermal and hydro) and transmission power stations instead of
> teaming / bonding that depends on RSTP for redundancy.
> 
> 	Are you aware that there is already an implementation of HSR (High-
> availability Seamless Redundancy) in the linux kernel?  I believe HSR and PRP are
> defined by the same standard (IEC 62439-3), and are similar enough to interoperate
> to some degree.  Perhaps PRP would be better implemented as a variant within the
> existing net/hsr/ framework.
> 
> 	-J
> 
> 
> >> -----Original Message-----
> >> From: Veaceslav Falico [mailto:vfalico@redhat.com]
> >> Sent: terça-feira, 11 de Fevereiro de 2014 14:16
> >> To: Gustavo Pimentel
> >> Cc: netdev@vger.kernel.org
> >> Subject: Re: Bonding
> >>
> >> On Tue, Feb 11, 2014 at 01:53:32PM +0000, Gustavo Pimentel wrote:
> >> >Hi,
> >>
> >> Hi Gustavo,
> >>
> >> >
> >> >I'm writing you because because I'm have implemented a new mode (PRP
> >> >Parallel
> >> Redundancy Protocol) for bonding kernel driver. This new mode is
> >> quite simple, I don't know if you have heard about PRP, but it's a
> >> new standard that allows to overcome any single network failure
> >> without affecting the data transmission. The general idea resides on
> >> having two separate LAN (A & B) very similar and transmitting the
> >> almost the same frame through both LANs and the end device should accept
> one frame and discard the other according to a known mechanism.
> >>
> >> Isn't that the current 'broadcast' mode, where every packet is
> >> transmitted over all the slaves? After quick googling/reading I don't
> >> see any difference there, though I might have missed something.
> >>
> >> >
> >> >I have implemented this new mode on bonding driver, but I have some
> >> difficulties:
> >> >. Writing linux driver is quite new for me. I don't' know if exists
> >> >guide lines for
> >> driver coding.
> >>
> >> You can find everything under Documentation/, but without the code I
> >> can't tell you exact documents. CodingStyle and SubmittingPatches might be
> the first ones.
> >>
> >> Also, try CC-ing relevant people for more feedback, specifically
> >> bonding maintainers.
> >>
> >> >. I don't know how to submit the code to be include on kernel repository.
> >> >. Maybe another pair of eyes could find help to improve the writing
> >> >code for this
> >> mode.
> >>
> >> Try sending an RFC when net-next opens.
> >>
> >> >
> >> >I think my driver code is 99% complete. I'm currently testing with 3
> >> >equipments (1
> >> pc + 1 embedded device running both my modify bonding driver) and a
> >> third party equipment called RedBox.
> >> >
> >> >Would you be interested in participating / helping this project?
> >> >
> >> >With my best regards,
> >> >
> >> >Gustavo Gama da Rocha Pimentel
> >> >Power Systems Automation / Innovation & Development Efacec
> >> >Engenharia e Sistemas, S.A.
> >> >Phone: +351229403391
> >> >Disclaimer
> 
> ---
> 	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> 

bonding...

[David Miller]

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.

Re: bonding...

[Neil Horman]

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

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

Re: bonding...

[Andy Gospodarek]

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.

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.

How does that sound?

-andy

Re: bonding...

[Jay Vosburgh]

Andy Gospodarek <andy@greyhouse.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@us.ibm.com

Re: bonding...

[David Miller]

From: Jay Vosburgh <fubar@us.ibm.com>
Date: Thu, 03 Mar 2011 09:24:25 -0800

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

Someone needs to exist who can keep things going when you are too
busy.  Unless you're like me and never take a day off, you need
at least one co-maintainer if your subsystem has lots of daily
activity as bonding now does.

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

Netfilter has a JIT like matching engine coming soon, that could
be made generic and plugged into.

Re: bonding...

[Jay Vosburgh]

David Miller <davem@davemloft.net> wrote:

>From: Jay Vosburgh <fubar@us.ibm.com>
>Date: Thu, 03 Mar 2011 09:24:25 -0800
>
>> 	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.
>
>Someone needs to exist who can keep things going when you are too
>busy.  Unless you're like me and never take a day off, you need
>at least one co-maintainer if your subsystem has lots of daily
>activity as bonding now does.

	Agreed.  If Andy is amenable, we can make it official:

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d83e58..6402703 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1467,6 +1467,7 @@ F:	include/net/bluetooth/
 
 BONDING DRIVER
 M:	Jay Vosburgh <fubar@us.ibm.com>
+M:	Andy Gospodarek <andy@greyhouse.net>
 L:	netdev@vger.kernel.org
 W:	http://sourceforge.net/projects/bonding/
 S:	Supported


	-J

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

Re: bonding...

[Andy Gospodarek]

On Thu, Mar 03, 2011 at 12:43:10PM -0800, Jay Vosburgh wrote:
> David Miller <davem@davemloft.net> wrote:
> 
> >From: Jay Vosburgh <fubar@us.ibm.com>
> >Date: Thu, 03 Mar 2011 09:24:25 -0800
> >
> >> 	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.
> >
> >Someone needs to exist who can keep things going when you are too
> >busy.  Unless you're like me and never take a day off, you need
> >at least one co-maintainer if your subsystem has lots of daily
> >activity as bonding now does.
> 
> 	Agreed.  If Andy is amenable, we can make it official:
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d83e58..6402703 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1467,6 +1467,7 @@ F:	include/net/bluetooth/
>  
>  BONDING DRIVER
>  M:	Jay Vosburgh <fubar@us.ibm.com>
> +M:	Andy Gospodarek <andy@greyhouse.net>
>  L:	netdev@vger.kernel.org
>  W:	http://sourceforge.net/projects/bonding/
>  S:	Supported
> 
> 

Acked-by: Andy Gospodarek <andy@greyhouse.net>

Re: bonding...

[David Miller]

From: Andy Gospodarek <andy@greyhouse.net>
Date: Thu, 3 Mar 2011 16:12:50 -0500

> On Thu, Mar 03, 2011 at 12:43:10PM -0800, Jay Vosburgh wrote:
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0d83e58..6402703 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1467,6 +1467,7 @@ F:	include/net/bluetooth/
>>  
>>  BONDING DRIVER
>>  M:	Jay Vosburgh <fubar@us.ibm.com>
>> +M:	Andy Gospodarek <andy@greyhouse.net>
>>  L:	netdev@vger.kernel.org
>>  W:	http://sourceforge.net/projects/bonding/
>>  S:	Supported
>> 
>> 
> 
> Acked-by: Andy Gospodarek <andy@greyhouse.net>

Applied, thanks.

Re: bonding...

[Andy Gospodarek]

On Thu, Mar 03, 2011 at 09:24:25AM -0800, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> >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?
> 

This is what I've been thinking about for a while, but it's basically
off the top of my head.  Of couse it seems reasonable to me....

As more people try to add functionality that exists in one mode to
another mode it becomes clear that the distinction between some of the
modes isn't clear anymore.  If we really want round-robin send on
802.3ad and xor modes, why do we have rr and xor anymore?  For that
matter, why not just get rid of active-backup too and add an option for
transmit algorithm to be active-backup.  It can get to be a slippery
slope when you start to combine them as it seems like you would just be
changing the language from 'mode' to 'transmit algoritm,' but I still
think it is worth thinking about.

Instead of thinking about the 7 modes of bonding that currently exist,
it makes more sense to me to think of the bond as being dynamic or
static (with 802.3ad being the only mode that is currently dynamic) and
then the user can select the transmit algorithm.  Obviously this isn't
totally flushed out since some transmit algorithms will be able to
support arp monitoring and some will not, but I suspect you know where
I'm going.

Re: bonding...

[Ben Hutchings]

On Wed, 2011-03-02 at 21:49 -0800, David Miller wrote:
[...]
> 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.
[...]

And preferably saying 'no' to most new features...

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: bonding...

[Stephen Hemminger]

On Thu, 03 Mar 2011 13:46:31 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:

> On Wed, 2011-03-02 at 21:49 -0800, David Miller wrote:
> [...]
> > 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.
> [...]
> 
> And preferably saying 'no' to most new features...

Agreed. It seems bonding has diverged from the standards and wants
to support every packet flow some user can think up.

Re: bonding...

[Eric Dumazet]

Le jeudi 03 mars 2011 à 08:31 -0800, Stephen Hemminger a écrit :
> On Thu, 03 Mar 2011 13:46:31 +0000
> Ben Hutchings <bhutchings@solarflare.com> wrote:
> 
> > On Wed, 2011-03-02 at 21:49 -0800, David Miller wrote:
> > [...]
> > > 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.
> > [...]
> > 
> > And preferably saying 'no' to most new features...
> 
> Agreed. It seems bonding has diverged from the standards and wants
> to support every packet flow some user can think up.

A simple setup that was working in 2.6.35 doesnt work anymore here

vlan.103 - bond0 - eth3   (tg3 nic)

With a bnx2 nic, it works

Not sure its a bond problem, more probably a vlan one...

bonding...

[David Miller]

Jay, there is quite a backlog of bonding patches in the queue right
now.

I'd like to know when you'll get to processing them because it's more
then two weeks (!!) for some of them and these folks are going to miss
the merge window out of no fault of their own.

Re: bonding...

[Jay Vosburgh]

David Miller <davem@davemloft.net> wrote:

>
>Jay, there is quite a backlog of bonding patches in the queue right
>now.
>
>I'd like to know when you'll get to processing them because it's more
>then two weeks (!!) for some of them and these folks are going to miss
>the merge window out of no fault of their own.

	I'll get through them today.

	-J

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