[ovs-dev] CT state - unknown bits mask generation

[Joe Stringer]

Hey Jesse,

With the CT datapath interface, a question came up about how mask
generation should work for bits that are unknown by userspace. This
links into exactly how the forward/backward compatibility of the bits
works as well.

In the current series that is up on ovs-dev, if userspace knows about
6 of the 32 bits in the ct_state field, then when generating the mask
it will match the value of the remaining 26 bits - all of the bits
that it doesn't know about. The kernel will verify that there are no
bits set in the key that it doesn't know about, then store the
key/mask. As the ct_state is only stored in a u8, when reserializing
it ends up zero-filling the remaining bits.

So, let's say a flow install with 0x00000020/0xFFFFFFE0 gets executed.
I'll assume for this example that 0x20 is the 'tracked' bit, bits <=
0x10 are defined (known by both kernel/userspace), and bits >= 0x40
are undefined. When userspace dumps such a flow, the kernel returns
0x00000020/0x000000E0. If we format these flags, we end up with
something like:

ct_state(+trk-[Unknown]-[Unknown])

Two specific follow-on questions:
- Should userspace instead wildcard all bits that it doesn't know about?
- Should the kernel reject exact-matching of bits that it doesn't know about?