From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by dpdk.org (Postfix) with ESMTP id 44400B63E for ; Mon, 16 Feb 2015 23:37:58 +0100 (CET) Received: by mail-qg0-f51.google.com with SMTP id z60so25435090qgd.10 for ; Mon, 16 Feb 2015 14:37:57 -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=QljVHMgp81zOdZtpJgdfTVVmXpsvKLjjPUUeL9Nk+ec=; b=ovAnV0DhosNMUL9Ti7MeF7EkA3i2qYVWmaCLDmQpG7iR1jVps2DTOrRxZT6AV/ZJwF YJUu4B1ycd2hb7rkzpHDTQA4Q+C+tuaUaJ9gPMPu5hRKVHOKHncm2lJgJj4+TQHj8fA5 liHzTUFev04VG9SPAZtI5dq0133i/Vt93xzuo= 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=QljVHMgp81zOdZtpJgdfTVVmXpsvKLjjPUUeL9Nk+ec=; b=j6YTKaJLtghM3UAylLvAhjCndcYVZr+OcUDhdFWZkonr1H3ajE8dBVPN1ntJUQ+kIs Xv9z2pACUgMVWK9r5F3P6NUIEAdcLp/8MZLa2h+A8E+70WIkXNMWq6iekx0F+lJ64kZk 4+gURovzZKfOoZ3Ou/YcffyfW5GpGpNi2AMZDZw+b/yIctmX1y6anmGR6UqkHow1/ezF WlLNMYwwJAi5TF4RXonsPtKCBe1x8WVuDz1rV4JEGRjdzX01brQ542daOj0DPQmwDv2Q DbyosoRjeSIK17omQ6/bLxTbexnf3em9jcJScH9RUrOqqMbc6Zj+8UNqL6zupMi4A64u YiLA== X-Gm-Message-State: ALoCoQnU03mNqPfWB47h/p2WIXbg2X2epaOwYnOagSToSRUMjOE8gBtnrJMr3Jkn/u22z4r7Kn3q X-Received: by 10.140.236.84 with SMTP id h81mr734477qhc.35.1424126277673; Mon, 16 Feb 2015 14:37:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.17.83 with HTTP; Mon, 16 Feb 2015 14:37:37 -0800 (PST) In-Reply-To: References: From: Andrey Korolyov Date: Tue, 17 Feb 2015 02:37:37 +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: Mon, 16 Feb 2015 22:37:58 -0000 On Fri, Feb 13, 2015 at 1:58 PM, Traynor, Kevin wrote: >> -----Original Message----- >> From: Andrey Korolyov [mailto:andrey@xdel.ru] >> Sent: Thursday, February 12, 2015 3:16 PM >> To: Traynor, Kevin >> Cc: dev@dpdk.org; discuss@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 wrote: >> >> -----Original Message----- >> >> From: Andrey Korolyov [mailto:andrey@xdel.ru] >> >> Sent: Tuesday, February 3, 2015 5:21 PM >> >> To: Traynor, Kevin >> >> Cc: dev@dpdk.org; discuss@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.