Quoting Jesse Gross :
On Thu, Oct 1, 2015 at 4:19 PM, wrote:
Quoting Jesse Gross :
On Tue, Sep 29, 2015 at 10:50 PM, wrote:
Hi-
I have been conducting scaling tests with OVS and docker. My tests
revealed
that the latency of ARP packets can become very large resulting in many
ARP
re-t
Quoting dwil...@us.ibm.com:
On the patch itself, can't we just make skb_get_hash() be able to
decode ARP? It seems like that is cleaner and more generic.
My first thought was to make a change in skb_get_hash(). However,
the comment in __skb_get_hash() state that the hash is generated
fro
Quoting Jesse Gross :
On Tue, Sep 29, 2015 at 10:50 PM, wrote:
Hi-
I have been conducting scaling tests with OVS and docker. My tests revealed
that the latency of ARP packets can become very large resulting in many ARP
re-transmissions and time-outs. I found the source of the poor latency t
skb_get_hash() returns a 0 (invalid hash) for arp packets resulting in same
ids_index for every arp packet. This results in a single ovs-vswitchd handler
thread processing every arp packet severely impacting the average latency of
arps. This change spreads the work evenly between all the handler t
Hi-
I have been conducting scaling tests with OVS and docker. My tests
revealed that the latency of ARP packets can become very large
resulting in many ARP re-transmissions and time-outs. I found the
source of the poor latency to be with the handling of arp packets in
ovs_vport_find_upcal
