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

William Tu u9012063 at gmail.com
Wed Jan 3 01:32:08 UTC 2018


Hi Yipeng,

Thanks for the reply.

On Tue, Jan 2, 2018 at 10:45 AM, Wang, Yipeng1 <yipeng1.wang at intel.com> wrote:
> Hi, William,
>
> Thanks for the comment. You are right. If the RSS hash does not consider the fields that matter, the situation you mentioned could happen.
>
> There are two design options for CD as you may find, when the signatures collide, we could either replace the existing entry (the current design), or still insert the entry into the cache. If we chose the second design, I think the situation you mentioned could be alleviated. We chose the first one mostly because of its simplicity and speed for the hit case. For example, if we allow multiple entries with the same signature stay in one bucket, then the lookup function needs to iterate all the entries in a bucket to find all the matches (for scalar version). And additional loops and variables are required to iterate all the matches. We expected to see some percentage of throughput influence for cache hit cases.

I think the cost of having multiple entries with the same signature is
too high, basically the CD lookup time increase from O(1) to O(n),
where n is the bucket size.

>
> But as you suggested, if the situation you mentioned is very common in real use cases, and RSS does not consider the vlan id, we could choose to not overwrite. Another option is to reduce the insertion rate (or turn off CD) as CD's miss ratio is high (this is similar to the EMC conditional insertion). Then the 100% miss ratio case can be alleviated. This is an easy change for CD. Or we could use software hash together with RSS to consider vlan tag, this could benefit EMC too I guess.
>
> There are many design options and trade-offs but we eventually want to have a design that work for most use cases.

I don't have any traffic dataset, but I would assume it's pretty
common that multiple tunneling protocols are deployed. That said, the
RSS hash, which is based on outer-header 5-tuple, might have little
difference and cause high collision when flows try to match fields
such as vxlan vni, or geneve metadata field. Matching the inner
packets requires recirculation, so the rss of inner 5-tuple come from
cpu, and I guess the CD's hit rate is higher for inner packets.

The DFC (datapath flow cache) patch seems to have similar drawbacks?
The fundamental issue seems to be the choice of hash function (RSS),
which only covers 5-tuple. Can we configure the rss hash to hash on
more fields when subtables uses more than 5-tuple?

Regards,
William


More information about the dev mailing list