[ovs-dev] [PATCH v3 05/16] conntrack: Periodically delete expired connections.

[Fischetti, Antonio]

Thanks Daniele, you did answer my questions.
Below my comments.

> -----Original Message-----
> From: Daniele Di Proietto [mailto:diproiettod at vmware.com]
> Sent: Tuesday, May 24, 2016 8:32 AM
> To: Fischetti, Antonio <antonio.fischetti at intel.com>
> Cc: dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v3 05/16] conntrack: Periodically
> delete expired connections.
> 
> 
> 
> 
> 
> 
> On 23/05/2016 08:07, "Fischetti, Antonio"
> <antonio.fischetti at intel.com> wrote:
> 
> >Hi Daniele,
> >I added one comment below.
> >
> >Regards,
> >Antonio
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of
> Daniele
> >> Di Proietto
> >> Sent: Tuesday, May 17, 2016 1:57 AM
> >> To: dev at 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