I don't see what problems would arise by saying that if the has is not present we return zeros for the hash value. Hashes serve a statistical function. The 1-in-4-billion chance that an actual hash value would be misinterpreted as unset simply means that the application will take some default action for those packets. Hardly cause for worry, especially for systems that actually produce hashes for each packet. Compare that to the benefit of eliminating all of the extraneous "if hash set" logic, it would seem to be a reasonable tradeoff.
On Tue, Aug 25, 2015 at 6:52 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote: > Hi, > > On 25/08/15 12:24, Bala Manoharan wrote: > >> The concern with adding additional has_hash_flag was that there will >> an "if check" in the system for every read hash value and since this >> comes in the fast path it might get costly if application reads it in >> several places. Anyhow that can be optimized by the implementation. >> > > If the implementation can guarantee that it generates some hash for every > packet, it can just return non-zero here, so the compiler can optimize it > out. > DPDK can be configured at pktio creation time to set up what kind of > packets should be handled by RSS, therefore what headers are in the hash. > But I guess we should expect that for non-supported protocols the hash > value can end up undefined, so we should check the flag for sure. I think > branch predictors can eliminate most of the performance impact. > > Zoli > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
