DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Jeff Guo" <jia.guo@intel.com>,
	"Wang, Haiyue" <haiyue.wang@intel.com>,
	"Yang, Qiming" <qiming.yang@intel.com>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	"Zhao1, Wei" <wei.zhao1@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>, <dev@dpdk.org>,
	"Zhang, Helin" <helin.zhang@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>, <barbette@kth.se>
Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs
Date: Fri, 28 Aug 2020 13:45:49 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61268@smartserver.smartshare.dk> (raw)
In-Reply-To: <77c760bb-7034-72b6-d4ba-c970764b7f3d@intel.com>

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jeff Guo
> Sent: Friday, August 28, 2020 8:40 AM
> 
> 
> On 8/28/2020 10:06 AM, Wang, Haiyue wrote:
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Morten Brørup
> >> Sent: Thursday, August 27, 2020 20:38
> >> To: Guo, Jia <jia.guo@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Xing, Beilei
> >> <beilei.xing@intel.com>; Zhao1, Wei <wei.zhao1@intel.com>; Zhang, Qi
> Z <qi.z.zhang@intel.com>; Wu,
> >> Jingjing <jingjing.wu@intel.com>
> >> Cc: Richardson, Bruce <bruce.richardson@intel.com>; dev@dpdk.org;
> Zhang, Helin <helin.zhang@intel.com>;
> >> Yigit, Ferruh <ferruh.yigit@intel.com>; barbette@kth.se
> >> Subject: Re: [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for
> PMDs
> >>
> >>> From: Jeff Guo [mailto:jia.guo@intel.com]
> >>> Sent: Thursday, August 27, 2020 12:10 PM
> >>>
> >>> The limitation of burst size in vector rx was removed, since it
> should
> >>> retrieve as much received packets as possible. And also the
> scattered
> >>> receive path should use a wrapper function to achieve the goal of
> >>> burst maximizing.
> >>>
> >>> This patch set aims to maximize vector rx burst for for
> >>> ixgbe/i40e/ice/iavf/fm10k PMDs.
> >>>
> >>> v2->v1:
> >>> 1:add fm10k driver case
> >>> 2:refine some doc
> >>>
> >> I now noticed that the vector functions also does:
> >> nb_pkts = RTE_ALIGN_FLOOR(nb_pkts, RTE_I40E_DESCS_PER_LOOP);
> >>
> >> I am not sure about this, but if I read it correctly, calling
> rte_eth_rx_burst() with nb_pkts = 33
> >> (not 32) would only return 32 packets, even if more packets are
> available. (I assume that
> >> RTE_I40E_DESCS_PER_LOOP is 32.) In this case, I guess that you need
> to read the remaining of the
> >> requested packets using the non-vector function in order to support
> any nb_pkts value.
> >>
> > This is vector instruction handling design requirement, like for
> avx2: #define ICE_DESCS_PER_LOOP_AVX 8,
> > if deep into the real loop handling, you will get the point why doing
> RTE_ALIGN_FLOOR. ;-)
> >
> > _ice_recv_raw_pkts_vec_avx2:
> > for (i = 0, received = 0; i < nb_pkts; i += ICE_DESCS_PER_LOOP_AVX,
> rxdp += ICE_DESCS_PER_LOOP_AVX)
> >
> > Maybe it is worth to tell PMD to stop using vector by calling
> rte_eth_rx_queue_setup with the application
> > burst size it wants.
> >
> >> That is, unless the rte_eth_rx_burst() API is extended with
> requirements to nb_pkts, as discussed in
> >> the other thread:
> >> http://inbox.dpdk.org/dev/20200827114117.GD569@bricha3-
> >> MOBL.ger.corp.intel.com/T/#mc8051e9022d6aeb20c51c5a226b2274d3d6d4266
> 
> 
> Agree with above haiyue said, and go through the discuss on the thread,
> i think vector path was born definitely for the spirit of dpdk, each
> driver could keep the performance base on
> 
> the instinct requirement and define what is the specific "max", the
> path
> option could give to app, it could static choose one when set up queue
> or dynamic but not the driver scope,
> 
> document could be add to AVI if need for benefit user.
> 

Based on the discussion in the other thread, I think a minimum requirement to nb_pkts will be accepted.

On that note, for the series:

Acked-by: Morten Brørup <mb@smartsharesystems.com>


  reply	other threads:[~2020-08-28 11:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 10:10 Jeff Guo
2020-08-27 10:10 ` [dpdk-dev] [PATCH v2 1/5] net/ixgbe: maximize vector rx burst for ixgbe Jeff Guo
2020-08-27 10:10 ` [dpdk-dev] [PATCH v2 2/5] net/i40e: maximize vector rx burst for i40e Jeff Guo
2020-08-27 10:10 ` [dpdk-dev] [PATCH v2 3/5] net/ice: maximize vector rx burst for ice Jeff Guo
2020-08-31  4:41   ` Zhang, Qi Z
2020-08-31  5:24     ` Jeff Guo
2020-08-27 10:10 ` [dpdk-dev] [PATCH v2 4/5] net/iavf: maximize vector rx burst for iavf Jeff Guo
2020-08-27 10:10 ` [dpdk-dev] [PATCH v2 5/5] net/fm10k: maximize vector rx burst for fm10k Jeff Guo
2020-08-27 12:38 ` [dpdk-dev] [PATCH v2 0/5] maximize vector rx burst for PMDs Morten Brørup
2020-08-28  2:06   ` Wang, Haiyue
2020-08-28  6:39     ` Jeff Guo
2020-08-28 11:45       ` Morten Brørup [this message]
2020-08-28 20:30       ` Stephen Hemminger
2020-08-31 14:27         ` 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=98CBD80474FA8B44BF855DF32C47DC35C61268@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=barbette@kth.se \
    --cc=beilei.xing@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=helin.zhang@intel.com \
    --cc=jia.guo@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=wei.zhao1@intel.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).