On Tuesday, August 4, 2015, Traynor, Kevin <kevin.tray...@intel.com> wrote:
> > > -----Original Message----- > > From: dev [mailto:dev-boun...@openvswitch.org <javascript:;>] On Behalf > Of Jesse Gross > > Sent: Thursday, July 30, 2015 4:10 AM > > To: dev@openvswitch.org <javascript:;> > > Subject: [ovs-dev] [PATCH 2/2] dpif-netdev: Translate Geneve options per- > > flow, not per-packet. > > > > The kernel implementation of Geneve options stores the TLV option > > data in the flow exactly as received, without any further parsing. > > This is then translated to known options for the purposes of matching > > on flow setup (which will then install a datapath flow in the form > > the kernel is expecting). > > > > The userspace implementation behaves a little bit differently - it > > looks up known options as each packet is received. The reason for this > > is there is a much tighter coupling between datapath and flow translation > > and the representation is generally expected to be the same. This works > > but it incurs work on a per-packet basis that could be done per-flow > > instead. > > > > This introduces a small translation step for Geneve packets between > > datapath and flow lookup for the userspace datapath in order to > > allow the same kind of processing that the kernel does. > > > > There is a second benefit to this as well: for some operations it is > > preferable to keep the options exactly as they were received on the wire, > > which this enables. One example is that for packets that are executed > from > > ofproto-dpif-upcall to the datapath, this avoids the translation of > > Geneve metadata. Since this conversion is potentially lossy (for unknown > > options), keeping everything in the same format removes the possibility > > of dropping options if the packet comes back up to userspace and the > > Geneve option translation table has changed. To help with these types of > > operations, most functions can understand both formats of data and > > seamlessly > > do the right thing. > > I tested std bi-directional phy-phy flows with dpdk to see if this affected > performance for them and it looks to be fine - same performance with and > without this patch. > That's great to hear. Thanks a lot for testing, I appreciate it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
