Message-ID: <AANLkTim-jswWzG=H0AQP5Z3byxoR1uXoV-ZhdaZ7+Sqd@mail.gmail.com>
Date:	Wed, 8 Sep 2010 16:37:17 -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 1:25 PM, Sven Eckelmann <sven.eckelmann@....de> wrote:
>> >  * 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.
>
> Hm, low overhead tunneling is one of the main parts, but if you think that it
> is easy to extend then fine.

I understand that tunneling needs to go in the kernel.  However, as I
said, several tunneling mechanisms already exist in Open vSwitch
(maybe one of them even already meets your needs) and adding another
one would certainly be less code than the approximately 9000 lines
that this patch entails.

>
>> >  * 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.
>
> It would mean that for example 5 packets goes over device 1, the next 5
> packets goes over

I'm assuming that those packets are from different higher level flows,
right?  Otherwise you will have significant reordering issues.
Assuming that is the case, then yes, this is possible and is how Open
vSwitch implements bonding purely in userspace.

>
>> > * directly influence the traffic flow, i.e., ARQ for broadcasts,
>
> Could you please comment on that one (taken from Mareks mail). Think about
> that one:
>  * A Broadcast packet must be send over wifi (adhoc)
>  * This packet is probably dropped due to some interferences. So each node
>   must transmit the broadcast more than one time to be (with a good chance
>   successful). This is quite essential on l2 based adhoc wifi mesh networks
>   (as tests showed - but please ask Marek for the actual test setups)

This isn't something that Open vSwitch currently has support for since
it expects the properties of Ethernet, which is best effort, and
assumes the upper layers will do any retransmission if desired.
However, I know that for lossy wireless networks sometimes this is not
sufficient.  Open vSwitch has a virtual port abstraction in the kernel
that works well for this type of application specific code and is
where I would expect you to put your tunneling protocol.  I suspect
that this may fit in there as well.  Again, I understand that there
are some areas where the existing Open vSwitch does not exactly fit
all of your needs.  However, I think that you will find that the parts
of the kernel that require extension are actually quite small and well
abstracted.
--
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