From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [108.178.14.82]) by dpdk.org (Postfix) with ESMTP id B1BB47288 for ; Sun, 25 Mar 2018 12:33:13 +0200 (CEST) Received: from ns1.es18.siteground.eu ([37.60.250.193] helo=es18.siteground.eu) by se14.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f02xb-0006NQ-KX for users@dpdk.org; Sun, 25 Mar 2018 05:33:12 -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: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eG8rASLmpTqbTQX4P/wbNSmj4kuyZqEXUnuU3PBjBrs=; b=S2HiD/fqlRXqnKhcwAUf/+/e1N Cy/HyFbmbJXyWPsuzLOz6mYZb1oN6K+x/PZzrs2oyV2Ij84sThtJ+cSYwAvFHkmRIn2zG5fbCDvoP FNQuUniCX1bCbtRz2c5ekm6tKz8qEzI+4xoPopsvYafxGI4U8tD6kEq6rKXuIe4SiNiXbAd1PERUv pOboi1+vZngv/7US0Mrd2nZ2lMxJCZvzipzcffLGxYYxGolWjITH01F7rUYtprtZ1s8h6k3Rh6MWL LJNgTVY15lJrsMb34Oxje+GuTDxq+xQp7nzokkukAcjdOGeooNIaNAuW8C3NnCrs1AKlXitJzNZph 7vLx8ZhA==; Received: from [89.64.59.78] (port=19178 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 1f02xa-000B3E-E1 for users@dpdk.org; Sun, 25 Mar 2018 12:33:10 +0200 To: users@dpdk.org From: Filip Janiszewski Message-ID: <1d7ceec8-f9c8-47d1-9274-31f4527edab5@filipjaniszewski.com> Date: Sun, 25 Mar 2018 12:33:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 7bit 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.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5q08Fn0hXda1zwZWq8YMbVB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO1v+PcEVtX7KZY7H5dkGCkxVjyn5UrUp4n4yKOOaq9AxNApe8luDBxDSm1J+hZRDMVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5cVGOG4DZYLJ/ZEcYZiqpFpGvPI2weg8WovFB YtDlTWOCPEeIMuyv9jqjNDaSpvFZLIAU8ez44E+JWMw7Rl2atQ89fDMXMSCcekoBNn9luNM9BNSM IeL844hdb5YC9oOas7rU/0aIzyPhsTjj9F2Uj2np7WJJ+GJanNasdrRWmdTk1OYQipoNB7xXL6n1 VuxxKjVMiaBuTf+Rjw1QjE94ZiObofOmVZ8jq2JCzFshGkbfX8TdqEXkwxwMjsp2mNApnxCbUh0d 2Cp8GYai7wEkBWWLX2ZbQb3UJKihEmoDuwh4Xlnjt820wyOY6l7qz/EbxxIFeBwctNa7tcu4kuCT Y2Gm+V69KgijJv/RSMoKe4Roh9VoIekQHpwUfpYnEThmCIGvANlNxRBYg0mvjXu8jm8zyrlCZlEq VNkwr1LUd0c9ObKbliwIKbcAkRLlMOQO2psyaUhfbXPQa2vJsM8bS/0RgEKd5Af8TFtuUNT3AUL/ Bm2BorTO8urg3zcgbWTr++pa2rrkAvotSRMFGEx6gvyorF8t5s3CctGlk6RRSzVgqh6QRqU5GaS6 PPUF2ESnw/yiGRY2Zn3XFYy9klX3EORLFzJfkuCyHJspVwENsI3MySEj7fwLz33nMnt8v2VA/+5O ROCVdibkm3Z8EGNwow8lQfkofTe5/DXB+7G2TDQE2B27pLze5x2F3f3q/8q8Z4gPSaCwLovvd5y1 OAKAGsStknsMa5xMcOok/WzPHhmPM5RdDbldsd3W2fWGqe5GzM60voqUUzJmvILAkkfgIF3SCJaT rNJp4Ar93JZTicsA5Bh9iX4taS2IqYImqp7pptGGXhtx4IgALSyGwICYQAvE3QObr5vmOgqfH6mP IgW3E6IYfYCJr6H44pXAT78t7ZcWAEoln1+9c4x2t03L3joZTxWp67LwZuUVOGlcECsxL7hrJSk6 0SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Subject: [dpdk-users] Packets drop while fetching with rte_eth_rx_burst 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 10:33:13 -0000 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