DPDK usage discussions
 help / color / mirror / Atom feed
* Re: [dpdk-users] rte_eth_tx_burst reliability
       [not found] <CAMkTTJODO9RDXHCcr2oQ6MThtC98yN_AHwO-fQLEJL0_UgawOQ@mail.gmail.com>
@ 2018-10-16 16:01 ` Stephen Hemminger
  2018-10-16 16:22   ` Amedeo Sapio
  0 siblings, 1 reply; 2+ messages in thread
From: Stephen Hemminger @ 2018-10-16 16:01 UTC (permalink / raw)
  To: Amedeo Sapio; +Cc: users

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-users] rte_eth_tx_burst reliability
  2018-10-16 16:01 ` [dpdk-users] rte_eth_tx_burst reliability Stephen Hemminger
@ 2018-10-16 16:22   ` Amedeo Sapio
  0 siblings, 0 replies; 2+ messages in thread
From: Amedeo Sapio @ 2018-10-16 16:22 UTC (permalink / raw)
  To: stephen; +Cc: users

Hello Stephen and thanks for your reply.

I understand that the function will send less packets if the ring is full.
According to the documentation, the return value is the number of packets
actually stored in transmit descriptors of the transmit ring.

In fact, to send all the packets, I have:

do {
    n_pkts = rte_eth_tx_burst(dpdk_par.portid, 0, &tx_pkts_burst[sent],
n_mbufs - sent);
    sent += n_pkts;
} while (sent < n_mbufs);

The problem that I am facing is that the function returns X (so X packets
are inserted in the ring), but less than X packets are transmitted.

---
Amedeo


On Tue, Oct 16, 2018 at 7:01 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> 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.
>
> --
>
> This message and its contents, including attachments are intended solely
> for the original recipient. If you are not the intended recipient or have
> received this message in error, please notify me immediately and delete
> this message from your computer system. Any unauthorized use or
> distribution is prohibited. Please consider the environment before
> printing
> this email.
>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-10-16 16:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAMkTTJODO9RDXHCcr2oQ6MThtC98yN_AHwO-fQLEJL0_UgawOQ@mail.gmail.com>
2018-10-16 16:01 ` [dpdk-users] rte_eth_tx_burst reliability Stephen Hemminger
2018-10-16 16:22   ` Amedeo Sapio

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).