the role of --enable-flow-dynamic flag

[hamidgh09]

Hello,

I have a problem understanding the goal of having --enable-flow-dynamic tag in the configuration.
From my understanding, Fastclick keeps a list of FCBs to store states per flow and indexes are coming from the FlowManager and corresponding hash table. So, to acquire one, you check the hash table and the "seen" flag inside the fcb, and for releasing them it should go through the timer wheel process and etc.

If it is correct, then I don't get the meaning for "automatically acquire and release flow control blocks" in the flag description and I would appreciate any heads up.

[tbarbette]

You understand correctly the "normal" mode, indeed.

The missing use-case is when you want to handle differently the FCB than using a global timer. For instance, if you want to prevent the release of a certain flow, typically because the other direction of the TCP flow is waiting for a FIN ACK. Or some flows need a longer timeout, or...
The solution is --enable-flow-dynamic that will add (atomic if --enable-flow-atomic) usage counter for all FCBs. Then your element does a fcb_acquire() that will prevent releasing the current flow until your element does a fcb_release().

That flag is needed for the context sub-system (CTX elements, --enable-ctx) that come from the MiddleClick paper to read or change TCP payload (and other) on the flight. There you can't just rely on a long timer, you need that more refined mechanism.

There is a caveat : most FlowIPManger* elements will not even look for the usage counter. CTXManager and CTXDPDKManager are the only ones that actually follow the usage counter. But it's just a matter of a few ifdefs.

[hamidgh09]

aha, I see. Then it makes sense that enabling the flag is kind of costly for the NF.
Thank you for the explanation.