[ovs-dev] [tun_id64 4/4] Expand tunnel IDs from 32 to 64 bits.

Ben Pfaff blp at nicira.com
Thu Dec 2 17:56:55 UTC 2010


On Wed, Dec 01, 2010 at 05:20:51PM -0800, Jesse Gross wrote:
> On Wed, Dec 1, 2010 at 3:59 PM, Ben Pfaff <blp at nicira.com> wrote:
> > On Wed, Dec 01, 2010 at 03:11:54PM -0800, Jesse Gross wrote:
> >> On Tue, Nov 30, 2010 at 5:16 PM, Ben Pfaff <blp at nicira.com> wrote:
> >> > Because datapath (ODP) actions are a fixed 64 bits in length, with 16 bits
> >> > dedicated to the action type, it requires two actions to set the full 64
> >> > bits of the tunnel ID: ODPAT_SET_TUNNEL followed by ODPAT_SET_TUNNEL_HI.
> >> >
> >> > It is awkward to extract or set the low or high 32 bits of an integer that
> >> > is in network byte order, so this commit also changes the various tunnel
> >> > ID fields to be in host byte order.
> >>
> >> I really don't like using two actions to set the tunnel ID and then
> >> also the byte swapping that it entails.  It feels a lot like a
> >> workaround to a compatibility problem that I'm not sure we have.
> >>
> >> Expanding the size of the actions seems inevitable for IPv6 (or
> >> potentially making them variable size).  Assuming that in most cases
> >> the number of actions is fairly small, there is probably very little
> >> overhead to increasing the size of the structure slightly.
> >
> > They will become variable-length in the netlink series, in which actions
> > are completely redone as sequences of Netlink attributes.  So i can
> > break out just that change from the netlink series and shove it in
> > before this one.  This requires some work and some review, but it's work
> > and review that would have to happen fairly soon anyhow.
> >
> > Or, like you say, we can make the actions fixed-length but longer, for
> > now.  That will waste 4 or 8 bytes for every datapath action other than
> > the set_tunnel_id one.  The number of actions can sometimes be very
> > large, although you are probably right that it is usually small, so this
> > might be OK.
> >
> > Which do you prefer?
> 
> Probably variable length is the right way to do it.  We can already
> get into situations where the amount of memory needed for a flood with
> the maximum number of ports is quite large and we probably shouldn't
> double it.

OK, I'll work on that today, then.

> One thing is that the Netlink series uses nla_for_each_attr, which
> causes us to length validation of the actions for each packet.  I
> would prefer to do this checking at flow setup and then skip it at
> packet processing time.

That shouldn't be a problem.




More information about the dev mailing list