On Mon, Feb 22, 2016 at 7:25 PM, Joe Stringer <j...@ovn.org> wrote: > 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. >
Is it inherited only at the start of the related/child connection, or at any time? If we set the mark on the parent connection after a related/child connection has also been allocated, will the mark still be inherited? It would be good to document these minor details for ct_mark and ct_label. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
