Remember that the purpose of RSS is simply to help spread arriving packets
to different receiving CPUs. Also, the RSS has itself is not static. It
takes as input the RSS key, which defines the packet fields over which the
hash is calculated, and the low order bits of it are used as an index into
the RSS indirection table. Both the keys and the indirection table are
dynamically updated by SW, so the interpretation of a given RSS hash value
will vary. So I can't look at a packet and tell you the RSS hash without
knowing what key to use, and the interpretation of the hash is dependent on
the indirection table (also not part of the hash). Once the packet has
been delivered in accordance with the information in the indirection table
the "meaning" of the RSS hash is no longer current. At that point it's
just a pseudo-random set of bits that is indirectly associated with what
were the packet fields of interest at the time the packet was originally
received.
On Thu, Aug 20, 2015 at 9:20 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote:
> Hi,
>
> On 20/08/15 11:53, Jerin Jacob wrote:
>
>> How about following change in OVS plarform specific packet_get_hash code.
>> odp_packet_rss_hash_set
>> kind of interface wont fit correctly in octeon platform as hash
>> identifier used by hardware in subsequent HW based queue operations
>>
>> static inline uint32_t
>> packet_get_hash(struct dp_packet *p)
>> {
>> #ifdef DPDK_NETDEV
>> return p->mbuf.hash.rss;
>> #else
>> #ifdef ODP_NETDEV
>> unit32_t hash;
>> hash = odp_packet_rss_hash(p->odp_pkt);
>> if (OVS_UNLIKELY(!hash)
>> hash = odp_packet_generate_rss_hash(p->odp_pkt);
>> return hash;
>> #endif
>> return p->rss_hash;
>> #endif
>> }
>>
>
> I was thinking about this too, but I see two problems:
>
> 1. OVS changes the hash if the packet is currently recirculated:
>
> https://github.com/openvswitch/ovs/blob/master/lib/dpif-netdev.c#L3125
>
> And as far as I can see, it doesn't recalculate the hash when the
> recirculation is finished. So the final hash of the packet at the end won't
> be what the platform would generate. OVS doesn't seem to care about it, I
> think the assumption is that the platform won't use this hash anymore, and
> it's role is finished after matching in EMC.
> My first idea to sort this out is to check for recirculation depth in
> netdev_send(), before the send of course. If it's true, then we can
> regenerate the hash using odp_packet_generate_rss_hash()
>
> 2. Minor thing, but if the platform is only able to do this from software
> (like DPDK), it should better be as fast as OVS's hashing at least. OVS
> uses CRC32 on SSE4 x64 CPUs, and Murmurhash on others. I don't know how do
> they compare e.g. with Toeplitz, but I guess they choose them because they
> are more suitable for the purpose.
>
> _______________________________________________
> 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
