[ovs-dev] [PATCH] dpif-netdev: Refactor datapath flow cache

[Wang, Yipeng1]

I think this is an interesting idea.

One caveat is that in this case we use the rules' field to infer the flows' field. If the rule
does not consider a field within which the flow has high entropy, it still does not help.
Or if the rule considers many fields but the flow does not have high entropy there, then
we add the incremental software hash overhead for little benefit.

I am not sure if that is common in real cases, I am more concerned with the second scenario, 
what do you think?

We should profile a little bit to see how much overhead the incremental CRC will
cost.

Thanks
Yipeng

>-----Original Message-----
>
>I like the idea of incremental hash using CRC. As for adding new
>field, can we do it on-demand without relying on user to choose which
>fields?
>
>Assuming that in the beginning, 5-tuple covers unions of all fields
>used in all subtables, so RSS works fine. As subtables increase, there
>might be new subtables using new fields, such as vlan, or tunnel
>metadata. At the moment (or periodically) when we detect new subtable
>using new field, then we consider adding new field into the hash
>function. So for simply traffic using 5-tuple, RSS remains effective
>and unchanged, for tunneled traffic or traffic matching more fields,
>this on-demand hashing approach can alleviate the collision. Of
>course, changing the hashing function requires rehashing all existing
>elements, so we should do it less frequent.
>
>Regards,
>William