On 22 February 2016 at 17:32, Russell Bryant <russ...@ovn.org> wrote: > > > 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?
At the time that you commit the related/child connection, it takes the mark from the original connection. That is the only time. > It would be good to document these minor details for ct_mark and ct_label. Sure, thanks for the reminder. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
