On Thu, Jan 4, 2018 at 5:41 PM, Wang, Yipeng1 <yipeng1.w...@intel.com> wrote: > 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? >
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 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
