From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id A8B0CC710 for ; Thu, 25 Jun 2015 21:20:46 +0200 (CEST) Received: by wicgi11 with SMTP id gi11so84966038wic.0 for ; Thu, 25 Jun 2015 12:20:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=crmnOe43KmHhqR6TJtAbYTrT7gH4CkE7uHvBdCG14ns=; b=cYis+oHukHlcTD54+cuBI4jBXzxhF3p6uhYQ94uOPDu9aM9UOQxB+SM+hvwYK+8j8/ Se/niC5vsKmZNuHonxYOQm9ZsMEFJCxSa/PmNHWjJYiRW2t18fayY8P/a3UsZIIMSUvb BRuz6n/Wl44sFUY2uFir8Bw7yreQMeKhF2ppcMUJA1YCUEXVtyssHPeg7fycHTwsuahI 21j+7D0TahlPquhiPXJMc9H3rY2NhdXch36aqNBDBkjeC/37aAim3nZ0LgvXYaxfWuZg 0gLX8u4KyDwyzpmRP7jkcy37nTDjDxBJq50eTpk4fkIc3OQOKj47tmZpCQuBDMSAi9MN ZKsQ== X-Gm-Message-State: ALoCoQlR8nZGYYGp0uXIidbLssHVkrxSRQHzDfO4hwNoKVKEk+f3sih8tesqbBsIFY/CUCt8ZkBJ X-Received: by 10.194.109.97 with SMTP id hr1mr31125038wjb.95.1435260046540; Thu, 25 Jun 2015 12:20:46 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-178-134-56.red.bezeqint.net. [79.178.134.56]) by mx.google.com with ESMTPSA id n6sm8968307wic.16.2015.06.25.12.20.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 12:20:45 -0700 (PDT) Message-ID: <558C548C.4070602@cloudius-systems.com> Date: Thu, 25 Jun 2015 22:20:44 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Thomas Monjalon References: <792CF0A6B0883C45AF8C719B2ECA946E42B2430F@DEMUMBX003.nsn-intra.net> <20150625151834.GA29296@mhcomputing.net> <558C2256.4070802@cloudius-systems.com> <1606901.Dh26nmAAAf@xps13> In-Reply-To: <1606901.Dh26nmAAAf@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 19:20:46 -0000 On 06/25/2015 09:44 PM, Thomas Monjalon wrote: > 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. As long as DPDK provides a mechanism for a runtime switch, the application can do that.