From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [107.6.149.12]) by dpdk.org (Postfix) with ESMTP id D7AEA5F6E for ; Sun, 25 Mar 2018 14:15:03 +0200 (CEST) Received: from ns1.es18.siteground.eu ([37.60.250.193] helo=es18.siteground.eu) by se12.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f04Y8-0005ya-TM; Sun, 25 Mar 2018 07:15:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=filipjaniszewski.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EGU1xZX8gp5WwqMU9JiJtop9InOb1B9IdGCqMgdulLE=; b=X9xoZ2bCCIDjXTgQMa6wT3hxbR U4vFDqvlZotZUj/XJY1GZ7oO93g0mML6Gh1BGBvSCvCF1wGYpsrKDWY4vZMtNBrL3AD5Let3CeMyP XMl/pu2APWa5HlDLfqeq+JHOEKUeYn81GQWsalCJyWMGvI8z2KsboPnN5fURuav31S4/zCYWkBmho D+nl3FcKpuQtCdwpCfxsosAN9PSxlLWkVM49vRHMYG2B3VnKIDrf/iv0nZzk8DQQyVsGb0NzsS9M+ 0Oe3GCoxRa3jqrWiZG6KCxQr6ZWwNwZUxdwzaYIdnmM/ZvdgpK/62KKMXuJfCg7a43e7PtfHKiqg1 m6+FObSQ==; Received: from [89.64.59.78] (port=19020 helo=localhost.localdomain) by es18.siteground.eu with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_34-9f6032f-XX) (envelope-from ) id 1f04Y7-0004r0-MB; Sun, 25 Mar 2018 14:14:59 +0200 To: MAC Lee , users@dpdk.org References: <277260559.2895913.1521977412628.ref@mail.yahoo.com> <277260559.2895913.1521977412628@mail.yahoo.com> From: Filip Janiszewski Message-ID: <8702e5e9-444b-70e5-6c5b-bff4fa1da18e@filipjaniszewski.com> Date: Sun, 25 Mar 2018 14:14:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <277260559.2895913.1521977412628@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: 37.60.250.193 X-SpamExperts-Domain: es18.siteground.eu X-SpamExperts-Username: 37.60.250.193 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=37.60.250.193@es18.siteground.eu X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gtl449syeqtP+bjkezy9Vp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO/HgfYHNbHMZNn8uVEcaq0h7zlMmPUBw2T1kZ99WSNUVKyQbMTN38/sVYZQ+M+ftKEGl z8CJSOMrvzx9TVg3RkVGGakzOTEHnvGsaSRm2vzQk5hzVqcRQipB56OduRZxKqXXAiWUc5KySDKf E/JmDHKXtcCZf0OdHMgfZW2SGg32Utx22w3qlBngfzyvVQNOGzsx2BQLZH40MQtHtB8vTAq8VfxO NtDvIRoHLfIDlUqSYSVLZvpS1kfaFtfjDudEZAMNwzSRr9TIm+vd5LtfSQMNa8sh5qcKvYnsSa35 QuNHGAFJ+4Vi0UkThksNRn9ICrsGOlWN3pRsVlO7BnVTW2964Bn/xFW1Emq7hJ1ivG4zukmd9wS3 TgOUAKXMmP2Nlqf2DNGP0n3HGosnygm28SP9hzvcC9WHTdL2y0kPKFsQeA6scZZwpzkCo4WoBCri 0gDAVE0LDqavceS6CUDOisguC54qR0DXEHm1B53l7yqV9+loV8IYwkmlIXLpYVwFMNOITDa6LxNU +V0EKPyMEBMRFir76D8s58kh7TOHJ2acgqHcaHpwjTKGY5d5T2g6o2H8Zc3L/FJ1KPSYItF5l5bU C6J4sy20YesqT/xGkQq1Y8nq2ni6sHp6BNFJVTZM/Fdv4PaU9kxZjkZq7J4zDgJ4uFI62hTfhknp jpF8Ud2i5W4jH8ZP6Sl/ALPTB2ijPbyBB4176ogfiivqiUXCLT2Ta9woBUmVrXIKzzDnYPqGJy3o 6dSxSY8tvUfgAkDcNCeoWTcRjNibMQm1dIqTNXViTNgLKRs0CRPw8TS+nLLWSjjX3OGF+QMOB1yX TYZGmxKEX45X5cxaHOJnVy0lU/PTJE6zgQXWE7AEFs3Dk7Ac3HZRW4chpyuV+EmSXBbXoXZJ0POK gHf7G3ONYBBKKZhZ3Wp92Kw4yIvr1Y+C5LXENHylfB1o84wTFuEwlOZkKPX7Be5jIapXwWmPitoW 7zJsA4xHKKX+usfft0Tv8HJOnHl2TRtBFGxCwNLr/WIXTpI2ODNrJ0shvKoIDg9/v5h/oqiUxFn0 NIn5IpDwFW7rw4ZiRgmKFHYBCYB9m9RC8w== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Subject: Re: [dpdk-users] =?utf-8?b?5Zue6KaG77mVICBQYWNrZXRzIGRyb3Agd2hpbGUg?= =?utf-8?q?fetching_with_rte=5Feth=5Frx=5Fburst?= X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 12:15:04 -0000 Thanks Marco, I'm running DPDK 18.02. I might understand that the counter is not implemented yet, but why rte_eth_rx_burst never returns nb_pkts? According to: http://dpdk.org/doc/api/rte__ethdev_8h.html#a3e7d76a451b46348686ea97d6367f102 "The rte_eth_rx_burst() function returns the number of packets actually retrieved, which is the number of rte_mbuf data structures effectively supplied into the rx_pkts array. A return value equal to nb_pkts indicates that the RX queue contained at least rx_pkts packets, and this is likely to signify that other received packets remain in the input queue." So in case of drops I would expect the rx queue to be full and rte_eth_rx_burst to return nb_pkts, but this never happen and it seems that there's plenty of space in the ring, is that correct? Thanks Il 03/25/2018 01:30 PM, MAC Lee ha scritto: > Hi Filip, > which dpdk version are you using? You can take a look to the source code of dpdk , the rxdrop counter may be not implemented in dpdk. So you always get 0 in rxdrop. > > Thanks, > Marco > -------------------------------------------- > 18/3/25 (週日)，Filip Janiszewski 寫道： > > 主旨: [dpdk-users] Packets drop while fetching with rte_eth_rx_burst > 收件者: users@dpdk.org > 日期: 2018年3月25日,日,下午6:33 > > Hi Everybody, > > I have a weird drop problem, and to > understand my question the best way > is to have a look at this simple (and > cleaned from all the not relevant > stuff) snippet: > > while( 1 ) > { >     if( config->running == > false ) { >         break; >     } >     num_of_pkt = > rte_eth_rx_burst( config->port_id, >           >                 >         config->queue_idx, >           >                 >         buffers, >           >                 >         MAX_BURST_DEQ_SIZE); >     if( unlikely( num_of_pkt > == MAX_BURST_DEQ_SIZE ) ) { >         > rx_ring_full = true; //probably not the best name >     } > >     if( likely( num_of_pkt > > 0 ) ) >     { >         pk_captured > += num_of_pkt; > >         > num_of_enq_pkt = > rte_ring_sp_enqueue_bulk(config->incoming_pkts_ring, >           >                 >                 >     (void*)buffers, >           >                 >                 >     num_of_pkt, >           >                 >                 >     &rx_ring_free_space); >         //if > num_of_enq_pkt == 0 free the mbufs.. >     } > } > > This loop is retrieving packets from > the device and pushing them into a > queue for further processing by another > lcore. > > When I run a test with a Mellanox card > sending 20M (20878300) packets at > 2.5M p/s the loop seems to miss some > packets and pk_captured is always > like 19M or similar. > > rx_ring_full is never true, which means > that num_of_pkt is always < > MAX_BURST_DEQ_SIZE, so according to the > documentation I shall not have > drops at HW level. Also, num_of_enq_pkt > is never 0 which means that all > the packets are enqueued. > > Now, if from that snipped I remove the > rte_ring_sp_enqueue_bulk call > (and make sure to release all the > mbufs) then pk_captured is always > exactly equal to the amount of packets > I've send to the NIC. > > So it seems (but I cant deal with this > idea) that > rte_ring_sp_enqueue_bulk is somehow too > slow and between one call to > rte_eth_rx_burst and another some > packets are dropped due to full ring > on the NIC, but, why num_of_pkt (from > rte_eth_rx_burst) is always > smaller than MAX_BURST_DEQ_SIZE (much > smaller) as if there was always > sufficient room for the packets? > > Is anybody able to help me understand > what's happening here? > > Note, MAX_BURST_DEQ_SIZE is 512. > > Thanks > > -- BR, Filip +48 666 369 823