From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by dpdk.org (Postfix) with ESMTP id D3D5D20F for ; Fri, 6 Feb 2015 15:43:55 +0100 (CET) Received: by mail-qa0-f51.google.com with SMTP id f12so11015826qad.10 for ; Fri, 06 Feb 2015 06:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xdel.ru; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FfoPF+rLI0sZJ74TBMyPuVPqN9fW16ny+6E+wFsDsY0=; b=qYaXy3QO367PqL852fkbA4Z5n8LeZcBWIp18DeMkFJQgFRw0lm9CcvcaiHjWo351i2 5p6VPNizsi3GM4y5jORML9wKfL5HQp3L3jzEd9q6pD+Tlnyf9rYlmrjAg6yl/MPU6T2P DhNTonmN0s/gNpiiasnEV0x3FpDN8xDPgimFA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FfoPF+rLI0sZJ74TBMyPuVPqN9fW16ny+6E+wFsDsY0=; b=GuMka2X3PEotaz24VklWQuH231kWNJYhR0HNory0diIuHnWRdtkgiBocppvdxPZvC7 TIFcPS5EzYSfE6mfsXsDPPGb+r2j3rRTxYw8XN5VqL8NMT55m/4B0GgAM8Bu2bKHl0O4 cZhLDnNhAUJMt36VaJ3y0xO71f6BmyMl7RozLtkD8xqwlnOe0+b48usc7mpYNop7ZvET RsuwvGdlLu3ae4aXPUy+mrID/m2YBkAcWVJNjE24kReEJYvD7SNwh0eB0yXrgbLNH4kD 5G8Xw+N6MccayQ81B85fYIjU1Ox5G9qA5Rm4cLjnSsDnsfLC9JdQ0XZmRY8CAMmeV3k/ nkkQ== X-Gm-Message-State: ALoCoQn2/IYAkkcHf4HE0iaFLkYOIg9YtNz87BcHqqo3Wmh8PbVu/2waUVfo1Xs63TTvH7kDZxvk X-Received: by 10.224.124.16 with SMTP id s16mr8762946qar.72.1423233835359; Fri, 06 Feb 2015 06:43:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.17.83 with HTTP; Fri, 6 Feb 2015 06:43:35 -0800 (PST) In-Reply-To: References: From: Andrey Korolyov Date: Fri, 6 Feb 2015 18:43:35 +0400 Message-ID: To: "Traynor, Kevin" Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" , "discuss@openvswitch.org" Subject: Re: [dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:43:56 -0000 On Tue, Feb 3, 2015 at 8:21 PM, Andrey Korolyov wrote: >> 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). > >> >> Main things to consider are to isocpu's, pin the pmd thread and keep everything >> on 1 NUMA socket. At 11 mpps without packet loss on that processor I suspect you are >> doing those things already. > > Yes, with all tuning improvements I was able to do this, but bare > Linux stack on same machine is able to handle 12Mpps and there are > absolutely no hints of what exactly is being congested. Also both action=NORMAL & action=output: do manage flow control in such a way that the generator side reaches line (14.8Mpps) rate on 60b data packets, though very high drop ratio persists. With action=DROP or action=output:X, where X is another dpdk port, flow control establishes somewhere at the 13Mpps. Of course, using regular host interface or NORMAL action generates a lot of context switches, mainly by miniflow_extract() and emc_..(), the difference in a syscall distribution between congested (line rate is reached) and non-congested link is unobservable.