[dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0

[Andrey Korolyov]

On Fri, Feb 13, 2015 at 1:58 PM, Traynor, Kevin <kevin.traynor at intel.com> wrote:
>> -----Original Message-----
>> From: Andrey Korolyov [mailto:andrey at xdel.ru]
>> Sent: Thursday, February 12, 2015 3:16 PM
>> To: Traynor, Kevin
>> Cc: dev at dpdk.org; discuss at openvswitch.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 <kevin.traynor at intel.com> wrote:
>> >> -----Original Message-----
>> >> From: Andrey Korolyov [mailto:andrey at xdel.ru]
>> >> Sent: Tuesday, February 3, 2015 5:21 PM
>> >> To: Traynor, Kevin
>> >> Cc: dev at dpdk.org; discuss at openvswitch.org
>> >> Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0
>> >>
>> >> > 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.