Re: Packet drops during non-exhaustive flood with OVS and 1.8.0

On Fri, Feb 13, 2015 at 1:58 PM, Traynor, Kevin [off-list ref] wrote:

quoted

-----Original Message-----
From: Andrey Korolyov [mailto:andrey-5vqebrSIFTo@public.gmane.org]
Sent: Thursday, February 12, 2015 3:16 PM
To: Traynor, Kevin
Cc: dev-VfR2kkLFssw@public.gmane.org; discuss-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0

On Thu, Feb 12, 2015 at 6:05 PM, Traynor, Kevin [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Andrey Korolyov [mailto:andrey-5vqebrSIFTo@public.gmane.org]
Sent: Tuesday, February 3, 2015 5:21 PM
To: Traynor, Kevin
Cc: dev-VfR2kkLFssw@public.gmane.org; discuss-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0

quoted

These patches are to enable DPDK 1.8 only. What 'bulk processing' are you referring to?
By default there is a batch size of 192 in netdev-dpdk for rx from the NIC - the linked
patch doesn't change this, just the DPDK version.

Sorry, I referred the wrong part there: bulk transmission, which is
clearly not involved in my case. The idea was that the conditionally
enabling prefetch for rx queues (BULK_ALLOC) may help somehow, but
it`s probably will mask issue instead of solving it directly. By my
understanding, strict drop rule should have a zero impact on a main
ovs thread (and this is true) and work just fine with a line rate
(this is not).

I've set a similar drop rule and I'm seeing the first packet drops occurring
at 13.9 mpps for 64 byte pkts. I'm not sure if there is a config that can be
changed or if it just the cost of the emc/lookups

Do you mind to compare this case with forward to the dummy port
(ifconfig dummy0; ovs-vsctl add-port br0 dummy0; ip link set dev
dummy0 up; flush rule table; create a single forward rule; start an
attack)? As I mentioned there are no signs of syscall congestion for a
drop or dpdk-dpdk forward case.

Assuming I've understood your setup, I get a very low rate (~1.1 mpps)
without packet loss as I'm sending the packets from a dpdk port to a
socket for the dummy port

Yes, but in other hand flow control from the dpdk port allows line
rate to come in, despite the actual loss during the transfer inside
receiving instance. With drop/output to dpdkY port the horizontal
asymptote with congestion is somewhat lower and this is hardly
explainable.