On 05/07/2015 12:14 AM, Michał Purzyński wrote:
That were my results as well.
It would be worthwhile to investigate how the hash is generated in the
kernel. I remember, somewhere in the original patch that introduced
this functionality, developers decided to let the hardware generate
rxhash and pass it to user space to avoid L1 cache miss.
As we all know, 82599 hashing is no symmetric. But in my testing both
a->b and b->a traffic goes correctly to the same cluster. Maybe the
hardware hash is not used at all?
Depends, for example, in ixgbe which I have a couple of, you can see in
the driver that in ixgbe_process_skb_fields() the rxhash can be copied
from hw ring descriptor into skb_set_hash() [1] (only l3). Quite a number
of drivers support offload for that.
At latest, if your nic doesn't support l4 hash, then in pf_packet when
doing the fanout, skb_get_hash() [2] gets called to build one with the
kernel's flow dissector in sw; l4 in order to get a bit more entropy.
That's why queue mapping (qm) can be less costly in some cases, for example.
In any case, it also doesn't really matter if 'hash' is used, even 'rr' or
'rnd' should populate other pcaps, which I find strange that apparently it
was not the case by Ivan. Works from my side. Would be good if you could
clarify the questions from the other mail, Ivan.
I will dig deeper.
[1]
http://lingrok.org/xref/linux-net-next/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c#1593
[2] http://lingrok.org/xref/linux-net-next/net/packet/af_packet.c#1285
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
