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