On 19 February 2016 at 06:53, Russell Bryant <russ...@ovn.org> wrote: > On 02/18/2016 07:37 PM, Joe Stringer wrote: >> On 17 February 2016 at 18:12, Justin Pettit <jpet...@ovn.org> 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. >>> >>>> 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? >>> >>> Jarno or Joe, do you know how the connection tracker handles children of >>> deleted flows? There's the following comment in nl_ct_flush() in >>> lib/netlink-conntrack.c: >>> >>> /* Expectations are flushed automatically, because they do not >>> * have a master connection anymore */ >>> >>> If we delete a specific entry, will its children get removed, too? If >>> that's true, this problem shouldn't be that difficult--although it is a >>> little ugly. I think we just need to have ovn-controller periodically >>> sweep through the connection tracking entries looking for that bit, and >>> blowing them away. >> >> No. The parent connection holds a list of expected connections, and >> when it is cleaned up, those expectations are cleaned up as well. >> However, once an expectation has been fulfilled by packets matching >> the expectation, if you commit that connection then it has a life of >> its own. I don't see any link from parent to child connections in the >> conntrack structures, so it seems unlikely that this is possible with >> current APIs. >> >> I think the way to do this currently is to uniquely identify >> connection families with a ct_mark, and delete connections based on >> this identifier. > > Right now, I don't think we ever do ct(commit) for a packet with the > related state bit set. In that case, if we set ct_mark/ct_label on the > parent connection, will we see that value set when we see another > related packet? I think that will result in the behavior we're looking > for ...
The mark is inherited from the initial connection down to the related/child connection, but the label is not. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
