From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 25114A0350; Mon, 11 May 2020 10:31:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 813631C1F4; Mon, 11 May 2020 10:31:56 +0200 (CEST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by dpdk.org (Postfix) with ESMTP id 9D84A1C1DB for ; Mon, 11 May 2020 10:31:54 +0200 (CEST) Received: by mail-wr1-f42.google.com with SMTP id s8so9765839wrt.9 for ; Mon, 11 May 2020 01:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y8wZS7Z3u0srEvGcY2vF4FOTBkgnDhIiu0J4IAhGxjM=; b=lTn0OLhHYDtpmtcwD8v++W4Zr0xRmBjjtU/AoYn+uPAVPaZUUtw2RfweHXvnYU0jtR gN7iFSiV092JfKXov7Gjwqt8pxUCvC7b3TgO0i7PY/WwDfbXy3hW70ZJhuBoiwU1RDNp IRhY0C35llodkQoeZgYK4gPA+UKn5I7daryOtsQuCQbbTXzHFCwjsER/JiweXIBGWshT pjGoKJ/651hva4O8fvmsFKaiK24wCiP2QiROYUjD4tQrJxUSykC7lVEAZ1zRZPaZWp4n ZBx0ati5b7OEmVILqBRyUQGXyvIcxTnN7+n3+HJ6g9O9L9nm2y1tyHGZD1Zvpl53/hmr dbrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y8wZS7Z3u0srEvGcY2vF4FOTBkgnDhIiu0J4IAhGxjM=; b=HPYI0fpKrUsA5tBkmZxT2j91ek6ugXPVf5BKY6Nwj6exk4uAcvuB9qy6ERCbFxFt8s 3aXZ9Ylt+6ANClLlFtjnr5fKVzFZwfIUgIjkXmDrIuXtk1Egx/7Ep5tPmyTE1ppedcpq /mz7OcaooRIUw8WBZ6vs2mFoLwwfr9gu4iahpQ55PRpJjRmaM5IdCrkUeA1Y3P24x35g CAm579+dLU2686tIg4QGVFA7pJsjIGnTNr38pwfDnvSLQbXySgJqeLrmaYgjbl1HOx1p EpjBEID8YnleX85XqlRelr+PGV73ExeVI1fDxOgKI5hm7XAyozA1iKHAVoMThbFucy/z R5kg== X-Gm-Message-State: AGi0PuZZiax2PHuOAASBUU7orKO0ka5Z4oi+qNsyazKr1tM1Nqr4ORpA jN0lUUXbuaQLj0asYDzs4TyyN08DKv5A3Uq0o+Y= X-Google-Smtp-Source: APiQypKNDgGuHfT8JVO0cKWWXba3YCKIISp11H4ITAxkBWT4rOxKxsK/UJhPphN2Mvf4yhpEEWtvhRNcbQRipY1Bajs= X-Received: by 2002:adf:8302:: with SMTP id 2mr18120036wrd.114.1589185914200; Mon, 11 May 2020 01:31:54 -0700 (PDT) MIME-Version: 1.0 References: <2b48bda28dc245e0a9841d385c3a717f@intel.com> <3e437bd9f8154c9d972bebcd32860352@intel.com> In-Reply-To: <3e437bd9f8154c9d972bebcd32860352@intel.com> From: Prashant Upadhyaya Date: Mon, 11 May 2020 14:01:43 +0530 Message-ID: To: "Wang, Haiyue" Cc: "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] Regarding 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The reason for 1 mbuf is application design, the SDK should not drive the application design. Eg. in my case the poll loop is in control of another module which calls a 'get work' function which expects to be returned a single mbuf and therefore the simple way was to do poll of 1 mbuf and return it if it is found or return null to get work function. Of course there are ways around this. But I would consider it as a bug because nowhere in the documentation is it prohibited to do polling of 1 mbuf. And it works for other PMD's. If it doesn't give the best performance, it should be up to the application to use the API more efficiently, it should not mean that the usecase should stop working altogether if somebody polls for 1 mbuf. Regards -Prashant On Mon, May 11, 2020 at 11:58 AM Wang, Haiyue wrote: > > > -----Original Message----- > > From: Prashant Upadhyaya > > Sent: Monday, May 11, 2020 13:58 > > To: Wang, Haiyue > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] Regarding rte_eth_rx_burst > > > > Thanks Wang ! > > ...which begs the proverbial question -- is this a bug or a feature ? > > I would say it is a bug as the polling for 1 mbuf works for the other > > PMD's, worse still the setting to zero is done in a quiet manner > > leading to entire rx blockage if the caller keeps calling with polling > > for 1 mbuf and keeps wondering why the rx is not working. > > Maybe a feature, this is good for vector handling best performance. > A slow Rx ' i40e_recv_pkts' in 'drivers/net/i40e/i40e_rxtx.c' can handle > 1 mbuf, detail please refer to 'i40e_set_rx_function' > > Why 1 mbuf ? Why not loop one by one each received buffer after > calling rte_eth_rx_burst ? > > > > > Regards > > -Prashant > > > > > > On Sun, May 10, 2020 at 10:46 PM Wang, Haiyue wrote: > > > > > > > -----Original Message----- > > > > From: dev On Behalf Of Prashant Upadhyaya > > > > Sent: Sunday, May 10, 2020 22:06 > > > > To: dev@dpdk.org > > > > Subject: [dpdk-dev] Regarding rte_eth_rx_burst > > > > > > > > Hi, > > > > > > > > I recently started using X722 NIC which uses i40 PMD of DPDK. > > > > I am on DPDK 20.02. > > > > I am seeing that when I call the rte_eth_rx_burst with last argument > > > > as 1 (polling for 1 mbuf), then I am not receiving data via repeated > > > > calls. > > > > > > I saw this kind of issue many times. ;-) > > > > > > This is *burst* for vector mode: > > > > > > drivers/net/i40e/i40e_rxtx_vec_sse.c > > > > > > static inline uint16_t > > > _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_pkts, > > > uint16_t nb_pkts, uint8_t *split_packet) > > > { > > > .... > > > > > > /* nb_pkts shall be less equal than RTE_I40E_MAX_RX_BURST */ > > > nb_pkts = RTE_MIN(nb_pkts, RTE_I40E_MAX_RX_BURST); > > > > > > /* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */ > > > nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); <--- nb_pkts = 0, if you > > passed 1. > > > > > > > > > > When I go for calls to rte_eth_rx_burst with last argument as 32, the > > > > function does return the mbuf's as received data. > > > > > > > > Is this expected ? Or this is a bug in the i40 driver handling this NIC ? > > > > > > > > The polls to rte_eth_rx_burst with last argument as 1 works well for > > > > the ixgbe PMD for sure since I have been using X520 successfully with > > > > last argument as 1. > > > > > > > > Regards > > > > -Prashant