Message-ID: <AANLkTi=FVyLE6OHTd+_qDbzSLk6fY5j6wBOWkYA810Dj@mail.gmail.com>
Date:	Wed, 8 Sep 2010 12:54:23 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Sven Eckelmann <sven.eckelmann@....de>
Cc:	b.a.t.m.a.n@...ts.open-mesh.org, Andi Kleen <andi@...stfloor.org>,
	davem@...emloft.net, netdev@...r.kernel.org,
	b.a.t.m.a.n@...ts.open-mesh.net
Subject: Re: [PATCHv4] net: Add batman-adv meshing protocol

On Wed, Sep 8, 2010 at 11:58 AM, Sven Eckelmann <sven.eckelmann@....de> wrote:
> Jesse Gross wrote:
>> Potentially one way to do this is to build on top of Open vSwitch.  It
>> contains a pretty generic flow-based kernel module for forwarding data
>> packets and making simple modifications.  Control packets can be sent
>> to userspace to handle the routing logic, while data packets remain in
>> the kernel for performance.  This would dramatically reduce the amount
>> of code that needs to be in the kernel and may even help performance
>> by simplifying the fast path.
>>
>> I don't know the details of your protocol well enough to know if this
>> is feasible but it seems like something you might want to look into.
>> Open vSwitch is currently in the process of finalizing its interfaces
>> to prepare for upstreaming.
>
> It sounds interesting. I haven't looked into it yet, but maybe you could
> easily answer some questions:
>  * Does it allow to generate multiple net_devices on the system?

Yes.

>  * Does it allow to attach multiple net_devices to a single openvswitch
>   device?

Yes.

>  * Does the attaching of a net_device to a openvswitch device prevent it to be
>   added to another openvswitch device?

It can be set up in different ways, depending on the desired behavior.

>  * Does it propagate the information about the incoming device to the
>   userspace in case of the not routed packets (everything which should

I think the last part of your question got cut off.  However, packets
do include metadata about the input device.  Userspace would then be
able to use the normal Linux mechanisms to find out whatever it needs
(or look at its own information).

>  * Does it allow to append extra header information to the packet?
>  * Does it allow fragmentation of packets (not real fragmentation, but more
>   single split)?

I'm assuming that both of these questions are for tunneling.  Open
vSwitch currently supports a few different L2 over L3 tunneling
mechanisms and has a tunnel library that makes adding additional
protocols easy.  It probably can't do exactly what you need right now,
but it should be fairly easy to extend.

>  * Does it allow to define outgoing patterns (on which attached interface
>   goes the thing out again) on packet number or incoming device (the real
>   hardware device it was coming in)?

I'm not sure what you mean by "packet number".  It does allow you to
specify the output interface based on a number of factors, include the
input device.

>  * Is it possible to define rules like: "If this is a broadcast of an udp/ip
>   packet with target port 123 which may or may not have a vlan tag, but is
>   coming directly from the virtual device and is not routed by us, then
>   change the mac address to following"?

Yes.

>  * Can it be backported to old kernels (~2.6.21 - yes, their are "customers"
>   who need even older kernels due to the fantastic vendors out their)?

The kernel module currently supports 2.6.18+.
--
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