DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets
@ 2015-08-28 19:04 Masoud Moshref Javadi
  2015-08-29  3:32 ` Gaohaifeng (A)
  0 siblings, 1 reply; 4+ messages in thread
From: Masoud Moshref Javadi @ 2015-08-28 19:04 UTC (permalink / raw)
  To: dev

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

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

* Re: [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets
  2015-08-28 19:04 [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets Masoud Moshref Javadi
@ 2015-08-29  3:32 ` Gaohaifeng (A)
  2015-08-29 13:55   ` Masood Moshref Javadi
  0 siblings, 1 reply; 4+ messages in thread
From: Gaohaifeng (A) @ 2015-08-29  3:32 UTC (permalink / raw)
  To: Masoud Moshref Javadi; +Cc: dev

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

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

* Re: [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets
  2015-08-29  3:32 ` Gaohaifeng (A)
@ 2015-08-29 13:55   ` Masood Moshref Javadi
  2015-08-29 18:25     ` Vladislav Zolotarov
  0 siblings, 1 reply; 4+ messages in thread
From: Masood Moshref Javadi @ 2015-08-29 13:55 UTC (permalink / raw)
  To: Gaohaifeng (A); +Cc: dev

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
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
>

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

* Re: [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets
  2015-08-29 13:55   ` Masood Moshref Javadi
@ 2015-08-29 18:25     ` Vladislav Zolotarov
  0 siblings, 0 replies; 4+ messages in thread
From: Vladislav Zolotarov @ 2015-08-29 18:25 UTC (permalink / raw)
  To: Masood Moshref Javadi; +Cc: dev

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
> >

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

end of thread, other threads:[~2015-08-29 18:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-28 19:04 [dpdk-dev] rte_eth_rx_burst only returns up to 32 packets 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 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).