From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stephen@networkplumber.org> Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by dpdk.org (Postfix) with ESMTP id 7896F1B133 for <users@dpdk.org>; Tue, 16 Oct 2018 18:01:11 +0200 (CEST) Received: by mail-pg1-f172.google.com with SMTP id g2-v6so11051424pgu.11 for <users@dpdk.org>; Tue, 16 Oct 2018 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WZy7U701BHO8iQNtF7wOhU/xP62YrTNxwM+Z5KCwGgM=; b=XQbW/vGvqHqfVxpDhEsfgGUyu6Ocb+1zDx/8BkFmCUsZEg3BIUsyqmiGmULbhcjQzO aFE6DUNvpRr/w9IW0kFKeWa/4Q6Jz0jrQ5q12hUk9xQbJkb9PcrKRBIHK8lgFya3CzsH 9DenG+GTU7r95LXgRJvGFC8MIQhkvg1Bzxb27AbBxCqVk5Ck7ElH8Khsc8oZYGe0Kl6X ymCyXfixaiEHN007Bc47R0MHh85MA/KmD8i+CBRgAo7aRP5SPxtlnyut8HpSy6JSO+6Z dfC2OQGVwPmiNdzn4Kt1BUjj8GFKg8HTyF/W5JGzCisk8mfKxwoIVwlr935DZuUSTi9o IfvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=WZy7U701BHO8iQNtF7wOhU/xP62YrTNxwM+Z5KCwGgM=; b=HoFcFaAU19SYbUXnWLtVWRGzT4Cb7kAY/lcVuCoeM74H/nm0ZjxWedwFdQxEYk3qC5 Mp7IYQ6CXuAJeY5A2j722IEHEPPTHGbAOjgad/MvJ9Rzk+ik48ZtxT/ooyzITAxKNzjB f9X+3LsIkcht0VBLLoGBmZA4T/qHSzsVdENBceRQ1t7Ut4xfyCB9Gh8EwkmbgoloGtF8 FTFQELz/ncFLYZitpUyogOnhsOv07s0rX6IEdn7MAeu/+pleGD11NDKh9SClT2IQFlZv rtCtkpJrl4Jr8DPz7+xxWrUGjmAtxLaJ5k4yU2Ib6YQQHxyPQJUY67F5WnUzndSKTCxE 9XZg== X-Gm-Message-State: ABuFfoj8abkbY01Dj2V9/6i7y9Qq0QgcTWMpRHuiUB1SQcWKZjkZpbhV hAzZaDhZ2kBLR72vkkPQ7oRJUOpuswE= X-Google-Smtp-Source: ACcGV62BULDRW71NvGfv/ggPc3deM7lBjgkqV0dVgSq9Uy5FKaZaJFU8pUNiVLiiULSUL7EY7EcMfw== X-Received: by 2002:a63:8a41:: with SMTP id y62-v6mr20443984pgd.420.1539705670470; Tue, 16 Oct 2018 09:01:10 -0700 (PDT) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 189-v6sm17729167pfe.121.2018.10.16.09.01.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Oct 2018 09:01:10 -0700 (PDT) Date: Tue, 16 Oct 2018 09:01:07 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Amedeo Sapio <amedeo.sapio@polito.it> Cc: users@dpdk.org Message-ID: <20181016090107.45efe64d@xeon-e3> In-Reply-To: <CAMkTTJODO9RDXHCcr2oQ6MThtC98yN_AHwO-fQLEJL0_UgawOQ@mail.gmail.com> References: <CAMkTTJODO9RDXHCcr2oQ6MThtC98yN_AHwO-fQLEJL0_UgawOQ@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] rte_eth_tx_burst reliability X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 16 Oct 2018 16:01:11 -0000 On Tue, 16 Oct 2018 18:38:23 +0300 Amedeo Sapio <amedeo.sapio@polito.it> wrote: > Dear all, > > while using rte_eth_tx_burst() to send packets in batches, I see that, > sometimes, the amount of packets that the function says are sent, are not > actually sent. > > I am accumulating the return value of rte_eth_tx_burst() in a variable and, > at the end of the job, the value of the accumulator is greater than the > value of "opackets" in the device "eth_stats". > I see the same number of transmitted packets in eth_stats, eth_xstats and > on the other side of the cable, and this number is less than the sum of the > values returned by rte_eth_tx_burst(). > > So, my question is: in what case the rte_eth_tx_burst() function returns a > value that does not correspond to the real number of transmitted packets? > According to the documentation, the function is returning only the number > of packets that have been successfully inserted in the ring, so I assumed > the return value was reliable. > > Testbed: > NIC: Intel 82599ES > DPDK driver: igb_uio > DPDK version: 18.05 > Traffic: UDP packets, sized 174B, with IP and UDP checksum offload > If number sent < number requested it means the transmit descriptor ring is full. Application needs to handle this and retransmit, or drop in that case.