On 20/08/15 17:55, Jerin Jacob wrote:
On Thu, Aug 20, 2015 at 03:20:46PM +0100, Zoltan Kiss 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()
if its not true then other option could be to hold additional data in
ODP meta data.
I mean we only need to call odp_packet_generate_rss_hash if
recirculation depth is non-zero. Otherwise OVS won't touch the hash if
the platform makes sure there is a 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
DPDK do have low level HW accelerated API's for crc 4 and 8 bytes.
Implementing 5 tuple based on CRC on ODP-DPDK port will NOT be be any issue.
And armv8 also has advanced SIMD instruction for CRC 8,4,2 and 1 bytes
Yes, but DPDK would need to generate Toeplitz, not CRC, if the NIC is
using that. And it might be that it's fast when the NIC does it, but not
when the CPU.
I'm also considering to let the application know whether the platform
requires this hash to set before handed back to the platform (e.g. going
out). Platforms like DPDK doesn't care if the application modifies the
hash, it won't use it again. So even if it can calculate it fast, it
would be a waste of cycles. In that case the application wouldn't need
to worry when changing the hash.
compare e.g. with Toeplitz, but I guess they choose them because they are
more suitable for the purpose.
I guess RSS hash algorithm used Intel nic is Toeplitz to get good
packet distribution using RSS(not for lookup)
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
