[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEP_g=_RihjefiBcPPTjUxW7dMdey6Ufm_=yZW0y03CEXSfBoA@mail.gmail.com>
Date: Mon, 3 Oct 2011 09:20:58 -0700
From: Jesse Gross <jesse@...ira.com>
To: Jiri Pirko <jpirko@...hat.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
eric.dumazet@...il.com, bhutchings@...arflare.com,
shemminger@...tta.com, fubar@...ibm.com, andy@...yhouse.net,
tgraf@...radead.org, ebiederm@...ssion.com, mirqus@...il.com,
kaber@...sh.net, greearb@...delatech.com
Subject: Re: [RFC patch net-next-2.6] net: introduce ethernet teaming device
On Mon, Oct 3, 2011 at 4:37 AM, Jiri Pirko <jpirko@...hat.com> wrote:
> Sat, Oct 01, 2011 at 08:15:01PM CEST, jesse@...ira.com wrote:
>>On Fri, Sep 30, 2011 at 5:44 AM, Jiri Pirko <jpirko@...hat.com> wrote:
>>> This patch introduces new network device called team. It supposes to be
>>> very fast, simple, userspace-driven parallel to existing bonding device.
>>> Userspace library called libteam with couple of demo apps is available
>>> here:
>>> https://github.com/jpirko/libteam
>>> Note it's still in its dipers atm.
>>>
>>> team<->libteam use generic netlink for communication. That and rtnl
>>> suppose to be the only way to configure team device, no sysfs etc.
>>>
>>> In near future python binding for libteam will be introduced. Also
>>> daemon providing arpmon/miimon active-backup functionality will
>>> be introduced. All what's necessary is already implemented in kernel team
>>> driver.
>>>
>>> Plan is to support 8023ad in near future with it's logic mainly in
>>> userspace daemon as well.
>>>
>>> Please review, try, comment. All feedback would be much appreciated.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@...hat.com>
>>
>>Not to push my own agenda too much but you might want to take a look
>>at Open vSwitch. It uses the same strategy of userspace directed
>>bonding and already supports active-backup, 802.3ad, and quite a few
>>other networking tools all controlled by userspace.
>>
>>I know there's been a lot of talk and not a lot of action when it
>>comes to upstreaming but that's changing. We're fixing up a few loose
>>ends in the userspace/kernel interface and then intend to propose a
>>patch fairly soon.
>
> Looks interesting. From quick peak the code is much bigger and fairly
> complicated. The main reason for doing "team" is to do ethernet teaming
> in as much simple way as it can be done. Final user destination areas
> of openvswitch and team seem different to me.
Yes, to the end user Open vSwitch is clearly a much larger and more
complex component. I just thought it might be of interest to you
since it already implements some of the features that you are looking
at and the kernel portion, at least, has similar goals of pushing more
logic to userspace.
--
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