Jesse Gross wrote:
> * Does it propagate the information about the incoming device
> userspace in case of the not routed packets (everything which should
I think the last part of your question got cut off.
Or I simple was distracted and didn't finish the sentence. :)
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.
Hm, low overhead tunneling is one of the main parts, but if you think that it
is easy to extend then fine.
> * Does it allow to define outgoing patterns (on which attached
> 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
It would mean that for example 5 packets goes over device 1, the next 5
packets goes over
> * directly influence the traffic flow, i.e., ARQ for broadcasts,
Could you please comment on that one (taken from Mareks mail). Think about
* 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)
There are three basic components that you need running for Open
vSwitch: the main daemon, ovs-vswitchd, a lightweight configuration
manager, ovsdb-server, and the kernel module, openvswitch_mod. You
would then be able to write a userspace process to communicate with
the daemons to handle the above. As I mentioned, the encapsulation
would likely require some small additions to the kernel module for
your particular type of tunneling (unless you are flexible and can use
one of the existing mechanisms). However, that would be significantly
less kernel code than this patch. As a starting point, I would
recommend playing around with Open vSwitch as a normal switch to get a
feeling for its operation (see the INSTALL.Linux file in the source
distribution for instructions).
Without checking any facts: This sounds a little bit heavy - does it only
sound heavy and in reality is extreme slim? The problem is that it must run on
those low end, "please don't run code on me, because I cannot crunch numbers
and have no ram" machines like the FON2100 or WRT54GL.