[MidoNet-dev] Flow expiration

Tomohiko Kimura tomohiko at midokura.com
Wed Mar 4 00:16:09 UTC 2015

Without knowing much background, I think it sounds reasonable. Are there
any particular scenarios for which idle timeout works well but hard timeout


On Tue, Mar 3, 2015 at 11:29 PM, Duarte Nunes <duarte at midokura.com> wrote:

> Howdy,
> Currently flows are expired based on either a hard timeout, upon which
> they will be evicted from the kernel flow table, or based on an idle
> timeout, which requires us to periodically fetch the flow from the kernel
> flow table and check whether the flow is active or if we can evict it.
> Flows that have state, which we can assume to be the majority of them,
> always have a hard timeout, which works to bring the next packet in the
> flow to user space so we can re-push the state to the interested set of
> hosts.
> Retrieving a flow from the datapath is an expensive operation, since it
> acquires the ovs_mutex lock and prevents flow delete and flow create
> operations from making progress. If a flow is considered idle after we
> fetch it, another datapath operation is required to evict it.
> When the system is under load - the scenario that matters for this
> discussion - we are also evicting the oldest flows to make room for new
> ones and to bound the amount of memory used. Indeed, we always try to have
> room for new flows in the table. Any idle timeout flow that we evict with
> this mechanism essentially behaves like a hard timeout flow.
> With all this in mind, I wonder if it would just be better to give all
> flows a hard timeout. We can make adjustments to this value as necessary
> (e.g., tunnel flows should have a bigger timeout than normal flows).
> What do you think?
> Cheers,
> Duarte
> _______________________________________________
> MidoNet-dev mailing list
> MidoNet-dev at lists.midonet.org
> http://lists.midonet.org/listinfo/midonet-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20150304/a07d935d/attachment.html>

More information about the MidoNet-dev mailing list