From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id 2DE70C6F0 for ; Thu, 25 Jun 2015 20:45:58 +0200 (CEST) Received: by wiwl6 with SMTP id l6so26203111wiw.0 for ; Thu, 25 Jun 2015 11:45:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=oEAIqkgQBYf1p4mcPBzTLz9w0jOMww1YE26ojP8bkiU=; b=EkFsPT3aAzQUYkNqiyF3lc8kMalYjVHbRxKXiH3Wl2Y3qHQ31ZANCxAthNck9iAVTT 8U/MAjeOqvn3tTWkgBvs9KnrQG5Ad2NjQIa5fo6d+67l5F+0beQtUcSpa9ZQh3VNAugo 1A+QTfybzr3WBaLBHB9dFFyCwDJlAkKqV4o7zIJLj0B3/1bxRuBZRErlwx+mTHyahSEU zA0Cf4dV3TfcFPfRnZrceHw6iNKDQvCxhAtAUoKOEW8KZJ359wwVLCdcnyP6mhSikzHk G6QZkCI4hMRzFtBSMKTKivEnC/QozczQfyS5twyVNrqfLB+KFobrPGolSiwLRCBiGAzt e7Og== X-Gm-Message-State: ALoCoQk6WSmwrqUlIqmJPBMnsyJ8tTucUvf8r1A2OEZLLE1p+3kBJREJ7pIVEw4AW/RmLoJV740e X-Received: by 10.194.200.42 with SMTP id jp10mr80797427wjc.66.1435257958027; Thu, 25 Jun 2015 11:45:58 -0700 (PDT) Received: from xps13.localnet (157.16.90.92.rev.sfr.net. [92.90.16.157]) by mx.google.com with ESMTPSA id ej5sm46999163wjd.22.2015.06.25.11.45.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 11:45:57 -0700 (PDT) From: Thomas Monjalon To: Avi Kivity Date: Thu, 25 Jun 2015 20:44:51 +0200 Message-ID: <1606901.Dh26nmAAAf@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <558C2256.4070802@cloudius-systems.com> References: <792CF0A6B0883C45AF8C719B2ECA946E42B2430F@DEMUMBX003.nsn-intra.net> <20150625151834.GA29296@mhcomputing.net> <558C2256.4070802@cloudius-systems.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] VMXNET3 on vmware, ping delay 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: Thu, 25 Jun 2015 18:45:58 -0000 2015-06-25 18:46, Avi Kivity: > On 06/25/2015 06:18 PM, Matthew Hall wrote: > > On Thu, Jun 25, 2015 at 09:14:53AM +0000, Vass, Sandor (Nokia - HU/Budapest) wrote: > >> According to my understanding each packet should go > >> through BR as fast as possible, but it seems that the rte_eth_rx_burst > >> retrieves packets only when there are at least 2 packets on the RX queue of > >> the NIC. At least most of the times as there are cases (rarely - according > >> to my console log) when it can retrieve 1 packet also and sometimes only 3 > >> packets can be retrieved... > > By default DPDK is optimized for throughput not latency. Try a test with > > heavier traffic. > > > > There is also some work going on now for DPDK interrupt-driven mode, which > > will work more like traditional Ethernet drivers instead of polling mode > > Ethernet drivers. > > > > Though I'm not an expert on it, there is also a series of ways to optimize for > > latency, which hopefully some others could discuss... or maybe search the > > archives / web site / Intel tuning documentation. > > > > What would be useful is a runtime switch between polling and interrupt > modes. This was if the load is load you use interrupts, and as > mitigation, you switch to poll mode, until the load drops again. DPDK is not a stack. It's up to the DPDK application to poll or use interrupts when needed.