[ovs-dev] [PATCH] datapath: add ipv6 'set' action

[Jesse Gross]

On Wed, Nov 7, 2012 at 12:45 PM, Ansis Atteka <aatteka at nicira.com> wrote:

> On Tue, Oct 30, 2012 at 1:11 AM, Jesse Gross <jesse at nicira.com> wrote:
> > We could implement the equivalent actions in the userspace datapath as
> > well.  There aren't any complex dependencies here so it would be ideal
> > to maintain parity.
>
> I am thinking, where in the user-space datapath I should put that code
> that parses routing headers. Two options come into my mind:
>
> 1. In the parse_ipv6() function, when packets are parsed for the the
> first time. This would mean that I would need store this routing
> header flag somewhere in struct *flow. And then pass *flow all the way
> to my packet_set_ipv6() function. Would it be appropriate to store it
> there?
> 2. Visit routing headers one more time from my packet_set_ipv6()
> function. The ugly side of putting this code here, would mean that
> ipv6 headers will need to be parsed twice and there will be another
> function very similar to parse_ipv6(). Except this one will have to
> use ugly pointer arithmetic, because ofpbuf *packet buffer was already
> consumed.
>
> I think solution #1 would be better? What do you think Jesse?


I think it's important that we mirror the kernel datapath as closely as
possible (meaning #2) otherwise things will be more complex in the long
run.  Routing headers are rare enough that, while I think it's important
that we handle the case, I wouldn't worry too much about the performance.

It's probably possible to factor out some of parse_ipv6() so there isn't
too much overlap.  As far as the pointer arithmetic, you could always save
the current data pointer in the ofpbuf and then reset it after you are
done.  The data hasn't actually been consumed, it's just pointers in the
struct ofpbuf are being moved around when you pull.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20121107/4269741d/attachment-0003.html>