[ovs-dev] [tun_id64 4/4] Expand tunnel IDs from 32 to 64 bits.
Jesse Gross
jesse at nicira.com
Thu Dec 2 01:20:51 UTC 2010
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.
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.
More information about the dev
mailing list