On 02/17/2016 09:12 PM, Justin Pettit wrote: > >> On Feb 5, 2016, at 1:30 PM, Russell Bryant <russ...@ovn.org> wrote: >> >> >> Thank you for the write-up! This approach sounds great to me. Some >> small questions... >> >> 1) If we're only using 1 bit for now, is there any reason to use >> ct_label over ct_mark? The docs in ovs-ofctl(8) seem to suggest they're >> identical other than being 32-bit vs 128-bit. Would using the 32-bit >> ct_mark be beneficial in any way instead? > > I think ct_label is intended more for this bit-level twiddling, > whereas ct_mark is usually treated as a single 32-bit number. > Clearly, this doesn't really matter in practice, since OVS interfaces > with them the same. Also, I figure that we're going to need to > identify the ACL rule at some point, and I've been thinking ct_mark > is what we'd use for that. >
It seems the most convenient way to map conntrack entries to ACL entries is by UUID (128-bit), so ct_label would certainly be convenient for that. That'd leave us 32-bits for state - "32 bits of state should be enough for anyone!". We could easily change it, at least in the short term. Eventually it will become an upgrade pain point if we wanted to change it. >> 2) One thing not explicitly addressed in this write-up is traffic marked >> as related. I think the proposal means just adding a match on >> ct_label=0x1 where we match ct_state=+rel today and we just rely on a >> packet in the request direction of the main connection to set ct_label. >> That seems fine, but I wanted to clarify that point. > > That's a good point. Do you know if the existing OpenStack integration > handles related flows? It doesn't look like they're handled explicitly. What it's doing is pretty brute force. It actually looks like it's deleting things based on IP addresses, including connections that should still be allowed. I imagine the current code can result in a few dropped packets when rules change, depending on how rules are configured... -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
