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. 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. Thanks Yipeng >-----Original Message----- > >Hi Yipeng, > >I like the idea of using Cuckoo Distributer, but I also have some >doubts about the RSS hash collision. (Sorry for jumping into the >discussion.) > >If there are rules using fields outside the 5-tuple, for example: >rule1 match: 5-tuple and vlan_id >= 1024 >rule2 match: 5-tuple and vlan_id < 1024 >Then rule1 will have it's unique mask in subtable1 and rule2 has >another mask in subtable2. > >For packets with the same 5-tuple, but different vlan_id, they will >collide into the same CD hash table, and potentially pointing to the >wrong subtable. Since the current OVS-CD implementation (if I >understand correctly) will overwrite the existing CD hash entry, if >the traffic have patterns like one packet matching rule1 and another >matching rule2, and so on, then the lookup miss for rule1 will insert >entry pointing to subtable1, and the second packet targeting rule2 >will miss again and insert entry pointing to subtable2, and so on. In >the end the miss rate will be 100% in such a worst case? > >Regards, >William _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
