On Fri, Sep 28, 2012 at 11:12:24AM -0700, Jesse Gross wrote: > The kernel tunneling code currently needs to handle a large number > of operations when tunnel packets are encapsulated and decapsulated. > Some examples of this are: finding the correct tunnel port on receive, > TTL and ToS inheritance, ECN handling, etc. All of these can be done > on a per-flow basis in userspace now that we have both the inner and > outer header information, which allows us to both simpify the kernel > and take advantage of userspace's information. This ports the logic > from the kernel to userspace and also pulls in the tunnel-specific > configuration handling from netdev-vport.c. Once tunnel packets are > redirected into this code, the redundant pieces can be removed from > other places. > > Signed-off-by: Jesse Gross <je...@nicira.com>
I guess that DF inheritance is not an important feature? (Should we accept the option and just warn about it, for better compatibility?) In tunnel.c, I would move #include "tunnel.h" just after #include <config.h>, to ensure that tunnel.h is self-contained. In tunnel.c, we usually put a line break just before the function's name in a function definition. It looks like tnl_port_add__() succeeds if the tunnel type is invalid, but I don't know why. Oh, maybe I see--this layer is meant to be a sort of shim that leaves non-tunnels alone? Some kind of high-level comment (maybe in tunnel.h) would be helpful. In tnl_hash(), since you made sure that struct tnl_match is a multiple of 4 bytes, you could use hash_words() instead of hash_bytes() for a slight speedup. I didn't read tnl_find() or tnl_config_get() carefully. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
