DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vladislav Zolotarov <vladz@cloudius-systems.com>
To: Masood Moshref Javadi <masood.moshref.j@gmail.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets
Date: Sat, 29 Aug 2015 21:25:17 +0300	[thread overview]
Message-ID: <CAOYyTHaRn3yt2+byO9ZtgWrNdAB1WyjbneYtREd2ULgMtryeGQ@mail.gmail.com> (raw)
In-Reply-To: <CAKCrth0V58ySpLMU1K+ktCX2MRoTt39KLezp4HucKgy=53-ojQ@mail.gmail.com>

On Aug 29, 2015 16:55, "Masood Moshref Javadi" <masood.moshref.j@gmail.com>
wrote:
>
> Thanks a lot.
>
> So I assume the only way to see if there are more than 256 packets in the
> queue is to count them using rte_eth_rx_count

Sorry for bulging in but i think Masood rose a very important general
question here, which is: how do i check if there are more pending packets
in the PMD Rx queue without actually polling them (out)?

As far as i see it the short answer is you can't. Or more specifically -
you shouldn't. Because if it happens that your code depends on it - it most
likely doesn't fit the PMD model.

The thing is that u can actually go and query the Rx ring about the number
of pending packets but the truth is that by the time u get this query
result it may already be wrong since new packets have arrived.

The only correct way to deal with PMD Rx queue is to actually go and poll
for new packets: if there are some - handle them and if there aren't any -
poll again.

This is my understanding of this.

Thanks,
Vlad

> On Aug 28, 2015 8:32 PM, "Gaohaifeng (A)" <gaohaifeng.gao@huawei.com>
wrote:
>
> > Please see  _rece_raw_pkts_vec function.
> >
> > Here is part of its comments may explain this question
> > /*
> >  * vPMD receive routine, now only accept (nb_pkts ==
> > RTE_IXGBE_VPMD_RX_BURST)
> >  * in one loop
> >  *
> >  * Notice:
> >  * - nb_pkts < RTE_IXGBE_VPMD_RX_BURST, just return no packet
> >  * - nb_pkts > RTE_IXGBE_VPMD_RX_BURST, only scan
RTE_IXGBE_VPMD_RX_BURST
> >  *   numbers of DD bit
> > */
> >
> >
> >
> > Hi,
> >
> > The documentation of this method says: Applications implementing a
> > "retrieve as much received packets as possible" policy can check this
> > specific case and keep invoking the rte_eth_rx_burst() <
> >
http://dpdk.org/doc/api/rte__ethdev_8h.html#aee7daffe261e67355a78b106627c4c45
> > >function
> > until a value less than nb_pkts is returned.
> >
> > But the function returns at most 32 packets regardless of the burst size
> > parameter (nb_pkts). For example when I set the burst size to 256, it
only
> > returns 32 packets even though the queue has more packets. This means
that
> > I cannot rely on the returned value to know if there are >
> > 256 packets in the queue or not.
> >
> > Where this number 32 comes from? Is it because "PMD:
> > ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst
size
> > no less than 32." ?
> >
> > I use DPDK 2.0.0 and Intel 82599 10 G NIC.
> >
> > Thanks
> >

      reply	other threads:[~2015-08-29 18:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 19:04 Masoud Moshref Javadi
2015-08-29  3:32 ` Gaohaifeng (A)
2015-08-29 13:55   ` Masood Moshref Javadi
2015-08-29 18:25     ` Vladislav Zolotarov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOYyTHaRn3yt2+byO9ZtgWrNdAB1WyjbneYtREd2ULgMtryeGQ@mail.gmail.com \
    --to=vladz@cloudius-systems.com \
    --cc=dev@dpdk.org \
    --cc=masood.moshref.j@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).