The reason for 1 mbuf is application design, the SDK should not drive
the application design.
Eg. in my case the poll loop is in control of another module which
calls a 'get work' function which expects to be returned a single mbuf
and therefore the simple way was to do poll of 1 mbuf and return it if
it is found or return null to get work function.
Of course there are ways around this.
But I would consider it as a bug because nowhere in the documentation
is it prohibited to do polling of 1 mbuf. And it works for other
PMD's. If it doesn't give the best performance, it should be up to the
application to use the API more efficiently, it should not mean that
the usecase should stop working altogether if somebody polls for 1
mbuf.
Regards
-Prashant
On Mon, May 11, 2020 at 11:58 AM Wang, Haiyue <haiyue.w...@intel.com> wrote:
>
> > -----Original Message-----
> > From: Prashant Upadhyaya <praupadhy...@gmail.com>
> > Sent: Monday, May 11, 2020 13:58
> > To: Wang, Haiyue <haiyue.w...@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.w...@intel.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: dev <dev-boun...@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
