DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	 "Sun, Chenmin" <chenmin.sun@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1 0/4] get Rx/Tx packet burst mode information
Date: Fri, 27 Sep 2019 01:17:25 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB8773D6E702@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <20190926101517.505ab45c@hermes.lan>

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, September 27, 2019 01:15
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>;
> Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin
> <chenmin.sun@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v1 0/4] get Rx/Tx packet burst mode information
> 
> On Thu, 26 Sep 2019 16:36:09 +0000
> "Wang, Haiyue" <haiyue.wang@intel.com> wrote:
> 
> > Hi Stephen,
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, September 26, 2019 23:57
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>;
> > > Kinsella, Ray <ray.kinsella@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>; Sun,
> Chenmin
> > > <chenmin.sun@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v1 0/4] get Rx/Tx packet burst mode information
> > >
> > > On Thu, 26 Sep 2019 19:48:14 +0800
> > > Haiyue Wang <haiyue.wang@intel.com> wrote:
> > >
> > > > RFCv3 -> v1:
> > > > 	https://patchwork.dpdk.org/patch/59103/
> > > > 	https://patchwork.dpdk.org/patch/59104/
> > > > 	https://patchwork.dpdk.org/patch/59105/
> > > > 	https://patchwork.dpdk.org/patch/59106/
> > > > 	1). Use the function 'rte_bsf64' to iterate the options for
> > > > 	    getting the name.
> > > >
> > > > Haiyue Wang (4):
> > > >   ethdev: add the API for getting burst mode information
> > > >   net/i40e: support to get the Rx/Tx burst mode
> > > >   net/ice: support to get the Rx/Tx burst mode
> > > >   app/testpmd: show the Rx/Tx burst mode description
> > > >
> > > >  app/test-pmd/config.c                    | 29 +++++++++
> > > >  doc/guides/rel_notes/release_19_11.rst   |  9 +++
> > > >  drivers/net/i40e/i40e_ethdev.c           |  2 +
> > > >  drivers/net/i40e/i40e_ethdev.h           |  4 ++
> > > >  drivers/net/i40e/i40e_rxtx.c             | 72 +++++++++++++++++++++
> > > >  drivers/net/ice/ice_ethdev.c             |  2 +
> > > >  drivers/net/ice/ice_rxtx.c               | 54 ++++++++++++++++
> > > >  drivers/net/ice/ice_rxtx.h               |  4 ++
> > > >  lib/librte_ethdev/rte_ethdev.c           | 75 ++++++++++++++++++++++
> > > >  lib/librte_ethdev/rte_ethdev.h           | 82 ++++++++++++++++++++++++
> > > >  lib/librte_ethdev/rte_ethdev_core.h      |  5 ++
> > > >  lib/librte_ethdev/rte_ethdev_version.map |  5 ++
> > > >  12 files changed, 343 insertions(+)
> > > >
> > >
> > > A couple of meta comments:
> > > 1) Could this be part of dev_info_get somehow?
> > >
> >
> > https://patchwork.dpdk.org/patch/57624/
> > 'Think of a better way that doesn't break ABI.'  ;-)
> 
> That comment was made relative to 19.08, but 19.11 is the time where
> API/ABI breakage is allowed.
> 

Since 'rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)'
focuses on 'port' level, the new rx/tx_burst_mode API can support 'queue' level:
'rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id ...', in other
words, PMD can optimize their queues in Vector/Scalar/... modes for each queue,
not have to just one mode for all queues at the same time, this API can return
"Per Queue" information.

> > > 2) Why should application care? Is this just a test hook?
> >
> > https://patches.dpdk.org/cover/57623/
> > This is from FD.io VPP's bug, and finally, we come out
> > this API for application accessing the burst mode information.
> > It can be used as a simple trace or something like performance
> > analysis like why slow ? Not in vector, anyway, application can
> > get this burst mode information now, not just open PMD debug log
> > level.
> 
> From an architecture perspective, diagnostics are good but VPP is probably
> taking that too far.  It is possible to expose local symbols if they
> want to keep using dlsym() by adjusting linker flags. It is more that VPP
> is stripping everything.  Since VPP has chosen to go their own
> way is fixable inside VPP without changing DPDK. Also, long term VPP is
> going away from using DPDK drivers. Probably soon they will have their
> own drivers for i40e and ice anyway.
> 
> 
> The basis of my concern is that this is one of those kind of API's
> that creates long term technical debt around supporting it as other
> things change.

At first, we use 'string format' to make VPP happy, now, we use bit-fields
for general use.

People come, people go, even VPP left DPDK, now, testpmd is the first
user, and I think it is good for 'test' the PMD with friendly information:

testpmd> show rxq info 0 0

********************* Infos for port 0 , RX queue 0  *********************
Mempool: mbuf_pool_socket_0
RX prefetch threshold: 0
RX host threshold: 0
RX writeback threshold: 0
RX free threshold: 32
RX drop packets: off
RX deferred start: off
RX scattered packets: off
Number of RXDs: 1024
Burst mode: Vector AVX2       =============> direct information, not have to check the
                                             code and open debug to make sure every setting
							   is right.

testpmd> show txq info 0 0

********************* Infos for port 0 , TX queue 0  *********************
TX prefetch threshold: 32
TX host threshold: 0
TX writeback threshold: 0
TX RS threshold: 32
TX free threshold: 32
TX deferred start: off
Number of TXDs: 1024
Burst mode: Vector AVX2      =============>

      parent reply	other threads:[~2019-09-27  1:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 11:48 Haiyue Wang
2019-09-26 11:48 ` [dpdk-dev] [PATCH v1 1/4] ethdev: add the API for getting " Haiyue Wang
2019-09-26 13:41   ` Ye Xiaolong
2019-09-26 13:48     ` Wang, Haiyue
2019-09-26 11:48 ` [dpdk-dev] [PATCH v1 2/4] net/i40e: support to get the Rx/Tx burst mode Haiyue Wang
2019-09-26 13:49   ` Ye Xiaolong
2019-09-26 14:18     ` Wang, Haiyue
2019-09-26 11:48 ` [dpdk-dev] [PATCH v1 3/4] net/ice: " Haiyue Wang
2019-09-26 11:48 ` [dpdk-dev] [PATCH v1 4/4] app/testpmd: show the Rx/Tx burst mode description Haiyue Wang
2019-09-26 13:57   ` Ye Xiaolong
2019-09-26 15:57 ` [dpdk-dev] [PATCH v1 0/4] get Rx/Tx packet burst mode information Stephen Hemminger
2019-09-26 16:36   ` Wang, Haiyue
2019-09-26 17:15     ` Stephen Hemminger
2019-09-26 17:36       ` Ferruh Yigit
2019-09-27  1:17       ` Wang, Haiyue [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=E3B9F2FDCB65864C82CD632F23D8AB8773D6E702@shsmsx102.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=chenmin.sun@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=ray.kinsella@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=xiaolong.ye@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).