In addition to the routing table, the Linux networking stack provides an ARP cache, TTL decrement, etc. I don't think the optimizations you mention would be generally useful outside of some very specialized use-cases. We are developing some other optimizations that should improve overall performance.
--Justin On Aug 15, 2010, at 7:58 PM, Romain Lenglet wrote: > Hi, > > My understanding when using a 'gre' vport is that: > - the next hop to send a GRE packet is determined by looking up the Linux > routing table; > - each GRE packet is sent through the Linux in-kernel router for forwarding. > Is that right? > If so, I assume that this behavior is inherited from the original gre module. > > It would be nice: > - not to look up the Linux routing table, and to rely solely on the ovsdb > config for the port and/or the flow definitions / actions to determine the > next hop for GRE packets; > - to have all GRE packets just forwarded to another vport (of another > datapath or of the same datapath), like a patch vport, without going through > the Linux routing. > > That would make it very easy to separate the encapsulated traffic and the > non-encapsulated traffic into different datapaths, and to concentrate all the > control into OpenFlow controllers without having to setup Linux routing. > And I think it may make the gre vport implementation simpler. > > What are the plans regarding the gre vport implementation? > Is there any plan to make gre vports behave more like patch vports, to > simplify the control of GRE forwarding and have more control over it in the > controllers? > > Best regards, > -- > Romain Lenglet > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
