[ovs-dev] [PATCH] dpif-netdev: Translate Geneve options per-flow, not per-packet.

Jesse Gross jesse at nicira.com
Wed Aug 5 02:41:10 UTC 2015

On Tuesday, August 4, 2015, Traynor, Kevin <kevin.traynor at intel.com> wrote:

> > -----Original Message-----
> > From: dev [mailto:dev-bounces at openvswitch.org <javascript:;>] On Behalf
> Of Jesse Gross
> > Sent: Thursday, July 30, 2015 4:10 AM
> > To: dev at 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.

More information about the dev mailing list