Thanks Daniele, you did answer my questions. Below my comments. > -----Original Message----- > From: Daniele Di Proietto [mailto:diproiet...@vmware.com] > Sent: Tuesday, May 24, 2016 8:32 AM > To: Fischetti, Antonio <antonio.fische...@intel.com> > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v3 05/16] conntrack: Periodically > delete expired connections. > > > > > > > On 23/05/2016 08:07, "Fischetti, Antonio" > <antonio.fische...@intel.com> wrote: > > >Hi Daniele, > >I added one comment below. > > > >Regards, > >Antonio > > > >> -----Original Message----- > >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of > Daniele > >> Di Proietto > >> Sent: Tuesday, May 17, 2016 1:57 AM > >> To: dev@openvswitch.org > >> Subject: [ovs-dev] [PATCH v3 05/16] conntrack: Periodically delete > >> expired connections. > >> > >> This commit adds a thread that periodically removes expired > >> connections. > >> > >> The expiration time of a connection can be expressed by: > >> > >> expiration = now + timeout > >> > >> For each possible 'timeout' value (there aren't many) we keep a > list. > >> When the expiration is updated, we move the connection to the back > of > >> the > >> corresponding 'timeout' list. This ways, the list is always > ordered > >> by > >> 'expiration'. > >> > >> When the cleanup thread iterates through the lists for expired > >> connections, it can stop at the first non expired connection. > > > >[Antonio F] This ordering mechanism is interesting, but could we > loose its > >benefit in case of many TCP retransmissions? > >Or for ex. in a Telco environment, when we're tracking UDP > connections > >(GTP tunnels) between S-GW and P-GW? In this case all the apps > running > >on one mobile phone can share the same S-GW/P-GW UDP connection. > >So the overhead of pushing back on the conn list could be big. > > Hi Antonio, > > I'm afraid I'm not familiar with the use case you're describing. I > can tell > that from an OVN perspective, for example, there isn't much value in > sending > encapsulated (VXLAN, Geneve or STT) traffic to the connection > tracker.
[Antonio F] Ok, so no worries, I was describing a similar case of encapsulated traffic. > > In my benchmarks I found that pushing a connection to the back of a > list is > very cheap (I couldn't notice the difference) compared to the other > per-packet operations that we have to perform, like the lookup in the > hash > table. After all we're using a doubly linked list, and the > complexity of > pushing back an element is O(1) in the number of connections. Is > this the > overhead you're worried about? [Antonio F] Yes, you did answer my question. > > Have I completely misunderstood your question? :-) > > Thanks, > > Daniele _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
