From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Prashant Upadhyaya <praupadhyaya@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Regarding rte_eth_rx_burst
Date: Mon, 11 May 2020 06:28:00 +0000 [thread overview]
Message-ID: <3e437bd9f8154c9d972bebcd32860352@intel.com> (raw)
In-Reply-To: <CAPBAu3WLvEG9pxKUN7fRdcd-DZdzXGHNwHayE2BprftfgQQcWQ@mail.gmail.com>
> -----Original Message-----
> From: Prashant Upadhyaya <praupadhyaya@gmail.com>
> Sent: Monday, May 11, 2020 13:58
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Regarding rte_eth_rx_burst
>
> Thanks Wang !
> ...which begs the proverbial question -- is this a bug or a feature ?
> I would say it is a bug as the polling for 1 mbuf works for the other
> PMD's, worse still the setting to zero is done in a quiet manner
> leading to entire rx blockage if the caller keeps calling with polling
> for 1 mbuf and keeps wondering why the rx is not working.
Maybe a feature, this is good for vector handling best performance.
A slow Rx ' i40e_recv_pkts' in 'drivers/net/i40e/i40e_rxtx.c' can handle
1 mbuf, detail please refer to 'i40e_set_rx_function'
Why 1 mbuf ? Why not loop one by one each received buffer after
calling rte_eth_rx_burst ?
>
> Regards
> -Prashant
>
>
> On Sun, May 10, 2020 at 10:46 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Prashant Upadhyaya
> > > Sent: Sunday, May 10, 2020 22:06
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] Regarding rte_eth_rx_burst
> > >
> > > Hi,
> > >
> > > I recently started using X722 NIC which uses i40 PMD of DPDK.
> > > I am on DPDK 20.02.
> > > I am seeing that when I call the rte_eth_rx_burst with last argument
> > > as 1 (polling for 1 mbuf), then I am not receiving data via repeated
> > > calls.
> >
> > I saw this kind of issue many times. ;-)
> >
> > This is *burst* for vector mode:
> >
> > drivers/net/i40e/i40e_rxtx_vec_sse.c
> >
> > static inline uint16_t
> > _recv_raw_pkts_vec(struct i40e_rx_queue *rxq, struct rte_mbuf **rx_pkts,
> > uint16_t nb_pkts, uint8_t *split_packet)
> > {
> > ....
> >
> > /* nb_pkts shall be less equal than RTE_I40E_MAX_RX_BURST */
> > nb_pkts = RTE_MIN(nb_pkts, RTE_I40E_MAX_RX_BURST);
> >
> > /* nb_pkts has to be floor-aligned to RTE_I40E_DESCS_PER_LOOP */
> > nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP); <--- nb_pkts = 0, if you
> passed 1.
> >
> >
> > > When I go for calls to rte_eth_rx_burst with last argument as 32, the
> > > function does return the mbuf's as received data.
> > >
> > > Is this expected ? Or this is a bug in the i40 driver handling this NIC ?
> > >
> > > The polls to rte_eth_rx_burst with last argument as 1 works well for
> > > the ixgbe PMD for sure since I have been using X520 successfully with
> > > last argument as 1.
> > >
> > > Regards
> > > -Prashant
next prev parent reply other threads:[~2020-05-11 6:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-10 14:05 [dpdk-dev] Regarding rte_eth_rx_burst Prashant Upadhyaya
2020-05-10 17:16 ` Wang, Haiyue
2020-05-11 5:58 ` Prashant Upadhyaya
2020-05-11 6:28 ` Wang, Haiyue [this message]
2020-05-11 8:31 ` Prashant Upadhyaya
2020-05-11 8:40 ` Wang, Haiyue
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=3e437bd9f8154c9d972bebcd32860352@intel.com \
--to=haiyue.wang@intel.com \
--cc=dev@dpdk.org \
--cc=praupadhyaya@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.