From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id EDB80F936 for ; Mon, 19 Dec 2016 14:24:31 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id f82so100999828wmf.1 for ; Mon, 19 Dec 2016 05:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=HNG8nluJ5ZP3faT67oxNGRhs19ZeAPhwF+Xb6mpN6mo=; b=ycBPoB2S+Lt0GU7BVzealX6i5ojXaeDFh6GyoIcShCFHO23EHUPPu4ZsDEMHI7Wo2i XoCKIzcjpgtT+8OephB9AGRo0MV84kW0qNQ/oCtZ2/MbT94hH87RiDGJdkHCKvZ1eZXl w5upmXIyHDZnkYjSbpdUwx8MRydT0OxBA7PIitgK+bq7Eyacz4TB2lBsdlfMUBvgZ83M J+9shpfQm5HvZ/ipfPOYWdxXUdKO8+M4mvvhhYONpmS3JOexZbDJqR2QqL/DI+/77tIS sDPUZllQEQRH3o65o58UUE/TscCnTRURBzHK28+OlPF4txFRSn6DCUiDr+7y1U++QtQk RI9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=HNG8nluJ5ZP3faT67oxNGRhs19ZeAPhwF+Xb6mpN6mo=; b=QbZ/8mGS40gpd23PSA7+9jLWyx1E4mymasn9Hh500pwQ+xa3VXtqAUuLDAiTcQgTMn TyjwV3bHjaXWogkh7mbBEgeiDbqnNxe6iK8qoPBbVCIvz3FxB2MnbOgo1ZS630qhLU1i VERgLkf5924qgVa5FMWC6KfyNm2emcSJVFD0tFl/MWtCx8uJj3VXCvs4G+ZvQSxLjJR+ w63XoftfFo7pyMoFGOm9b/t9M9h8JDppNotmEeeDTeikj0a8p1dH/m6X8i9N2C7hHwiq QfAQDzEGfedlUcYJmem1cpYbRcV/5uK+Fv2Y289xm+28axVF2UEumjREyWSovHpLgk++ zcVQ== X-Gm-Message-State: AIkVDXJUOy4By92mMivSeH1V1RYH6eyiGgHbIHSs/7faP4cP7p65LEtuBXUTD/ksBPQvtNgI X-Received: by 10.28.111.70 with SMTP id k67mr13483984wmc.32.1482153871716; Mon, 19 Dec 2016 05:24:31 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id d64sm17191497wmh.3.2016.12.19.05.24.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 05:24:31 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, tom.barbette@ulg.ac.be Date: Mon, 19 Dec 2016 14:24:30 +0100 Message-ID: <1506956.nCsXY16HsG@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20161219102504.GA170848@bricha3-MOBL3.ger.corp.intel.com> References: <415214732.17903310.1481728244157.JavaMail.zimbra@ulg.ac.be> <1289578237.19546607.1481971405418.JavaMail.zimbra@ulg.ac.be> <20161219102504.GA170848@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] No packets received if burst is too small in rte_eth_rx_burst X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 13:24:32 -0000 2016-12-19 10:25, Bruce Richardson: > On Sat, Dec 17, 2016 at 11:43:25AM +0100, tom.barbette@ulg.ac.be wrote: > > Hi, > > > > Your comments made me saw the line "PMD: i40e_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 4 (port=0)." > > > > The problem was probably that I was under this limit... Is there a way to get that limit through a function or something? > > > > With 16.04 I received sometimes 5 or 7 packets with a burst_size of 4 which respects this limit. I see that "[dpdk-dev] net/i40e: fix out-of-bounds writes during vector Rx" fixed that, as the limit was in fact 32 no matter the message. > > > > At the end, what should be the minimal rx burst size? How to find it at runtime for any NIC? I imagine that vector rx will create a problem if I give a burst size of 1 even with a recent DPDK version, right? > > > > Sadly, there doesn't appear to be any way to discover this, and the i40e > driver requires at least a burst size of 4 even with the latest DPDK. > From i40e_rxtx_vec_sse.c: > > 243 /* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */ > 244 nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); > 245 > > I think in this case the gap is not so much having a discovery mechanism > to determine min burst size, but rather a driver gap so as to allow some > form of slower-path fallback when we get below min-size bursts for the > vector driver. Yes this is a severe bug. Please Tom, could you keep asking/monitoring this bug until it is fixed? Thanks for reporting.