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? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
