I agree with you guys on the issue with RSS hash. RSS is not originally designed for hash table so it is not flexible enough to be configured in the NICs. Smart NICs will be more capable to offload hash calculation etc, I think.
Another thing is I think it will not be very costly if we combine RSS with the software hash. We just need to use the RSS together with the Vlan field to calculate a new hash (using CRC hash which is fast). It is like what recirculation does. We do not need to hash 5-tuple again in software. User can choose which field they want to include into the hash for the hash table structures in OvS. What do you think? >-----Original Message----- >From: Fischetti, Antonio >Sent: Wednesday, January 3, 2018 1:13 AM >To: William Tu <[email protected]>; Wang, Yipeng1 ><[email protected]> >Cc: [email protected]; Tai, Charlie <[email protected]> >Subject: RE: [ovs-dev] [PATCH] dpif-netdev: Refactor datapath flow cache > >Thanks William for your comments. >Some replies inline. > >-Antonio > >> -----Original Message----- >> From: [email protected] [mailto:ovs-dev- >> [email protected]] On Behalf Of William Tu >> Sent: Wednesday, January 3, 2018 1:32 AM >> To: Wang, Yipeng1 <[email protected]> >> Cc: [email protected]; Tai, Charlie <[email protected]> >> 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 <[email protected]> >> 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 >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
