On Fri, Dec 14, 2012 at 09:34:16AM +1100, Dmitry Smirnov wrote:
> You did a fantastic work on "ifenslave" (interface to bonding capabilities in
> kernel) -- thank you.
Thank you too, as you also helped with it (although your changes will have to
wait for wheezy to be released before they can be uploaded to unstable).
> This new and experimental software has only potential to become an alternative
> to "ifenslave" one day.
I hope it does too.
> > Dramatically different? Many advantages? That tells me nothing. Instead
> > please just give a list of *user visible* advantages that libteam has over
> > bonding.
>
> Why focus only on user visible changes? Upstream is trying to make
> bonding/teaming safer, easier and more maintainable by moving it to user
> space.
Yes, but for the user of this software it really doesn't matter where the code
lives, and a statement like "dramatically different" does not convey any useful
information.
> To provide summary here I quote from above documents:
The following features team supports but bonding does not are, in my opinion,
useful to mention in the long description:
> [Feature] [Bonding] [Team]
> load-balancing for LACP support No Yes
> NS/NA (IPV6) link monitoring No Yes
> port priorities and stickiness ("primary" option enhancement) No Yes
> separate per-port link monitoring setup No Yes
Although that last item is very vague. The following items are not very useful
to mention, they just cover implementation details that are not important for
the end user, but only for developers:
> lockless TX/RX path No (rwlock) Yes (RCU)
> Logic in user-space No Yes
> Extensibility Hard Easy
> Modular design No Yes
The following items on the list are very vague:
> multiple link monitoring setup Limited Yes
> Performance overhead Low Very Low
> user-space runtime control Limited Full
And the last one is only interesting if there is actually anything else but
libteam which can make use of it:
> D-Bus interface No Yes
Similarly, the following statements are also not so interesting for the end
user which just wants to bond/team/trumk multiple Ethernet inferfaces, they are
only interesting for developers:
> ### Advantages comparing to bonding
>
> * Extensibility. Anyone can easily add features/change behaviour
> * Better system stability (daemon crash is always better than
> kernel panic/memory corruption etc.)
> * Better debugging posibilities.
>
> The goal of team device is to supersede bonding functionality
> and then kill it eventually.
So while all of that is true (although I don't think the bonding driver is
likely to crash at all), that shouldn't be mentioned in the description of the
package.
> P.S. I hope that answers your questions. Please let me know if you think
> teaming do not worth time spent on it.
I do not have anything against teaming, on the contrary. It is just parts of
the package description I object to :)
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
Attachment:
signature.asc
Description: Digital signature