Thanks William for your comments. Some replies inline. -Antonio
> -----Original Message----- > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev- > boun...@openvswitch.org] On Behalf Of William Tu > Sent: Wednesday, January 3, 2018 1:32 AM > To: Wang, Yipeng1 <yipeng1.w...@intel.com> > Cc: d...@openvswitch.org; Tai, Charlie <charlie....@intel.com> > Subject: Re: [ovs-dev] [PATCH] dpif-netdev: Refactor datapath flow cache > > Hi Yipeng, > > Thanks for the reply. > > On Tue, Jan 2, 2018 at 10:45 AM, Wang, Yipeng1 <yipeng1.w...@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. [Antonio] Hmm, I expect that adding some software hash computation would kill the performance. > > > > 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? [Antonio] This is a general issue due to the fact that RSS hash is computed on a pre-defined 5-tuple of the outer header. So it's not specific to the CD or the DFC implementations. For sure it affects the EMC. > 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? [Antonio] > > Regards, > William > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
