On Tue, Oct 6, 2015 at 4:10 PM, Joe Stringer <joestrin...@nicira.com> wrote: > 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?
I think the answer is probably yes to both of those questions. If you think about how a completely new attribute in the flow key would be handled, on upcall it would be ignored by userspace and supplied with no mask, which would result in it being wildcarded. Similarly, if userspace tried to install a flow with an attribute that the kernel didn't know about (which would be surprising since userspace is reacting to the kernel) then the kernel would reject that flow installation. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
