DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Slava Ovsiienko <viacheslavo@mellanox.com>,
	"Liu, Yu Y" <yu.y.liu@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	"Sun, Chenmin" <chenmin.sun@intel.com>,
	"Damjan Marion (damarion)" <damarion@cisco.com>
Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
Date: Sun, 3 Nov 2019 02:34:06 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB8773D8DE2D@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <AM4PR05MB3265E19B616FA4EF816C8DE6D27D0@AM4PR05MB3265.eurprd05.prod.outlook.com>

Hi Thomas, Slava,

Please see the inline reply in one place.

> -----Original Message-----
> From: Slava Ovsiienko <viacheslavo@mellanox.com>
> Sent: Saturday, November 2, 2019 16:39
> To: Liu, Yu Y <yu.y.liu@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh <ferruh.yigit@intel.com>;
> jerinjacobk@gmail.com; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Sun, Chenmin <chenmin.sun@intel.com>; Damjan Marion (damarion) <damarion@cisco.com>
> Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information
> 
> Hi
> > -----Original Message-----
> > From: Liu, Yu Y <yu.y.liu@intel.com>
> > Sent: Saturday, November 2, 2019 8:56
> > To: Wang, Haiyue <haiyue.wang@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>; Damjan Marion (damarion)
> > <damarion@cisco.com>; Liu, Yu Y <yu.y.liu@intel.com>
> > Subject: RE: [PATCH v1 3/3] ethdev: enhance the API for getting burst mode
> > information
> >
> > Add Damjan from FD.io for awareness...
> >
> > Hi Thomas,
> >
> > Long time no see. Sorry I use outlook which is not friendly to community
> > email.
> >
> > >Anyway I will propose to replace this API in the next release.
> > Will your plan be affected by API/ABI stable plan?
> > BTW, if you propose new change in next release, it will make DPDK
> > consumer(FD.io) to change again.
> > So even if it is not affected to the API/ABI stable plan, do we still have time
> > to get a solution for everyone in DPDK 19.11 with your
> > contribution/acceleration?
> >
> > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > Please be rest assured it is not the case.
> > This request is just from one FD.io project internal bug " tx/rx burst function
> > is shown as nil" reported by Chenmin.
> 
> Why just the presenting string with function name (possible with suffix) is not enough?
> I would like to see this API  (strings approach) in mlx5 either, dropping the entire feature
> does not look nice, as for me.
> 
> We could consider some requirements for the name suffices to distinguish whether
> function uses vector instructions and which ones if any.
> 
> > My understanding is DPDK behavior was taken as bug for someone in FD.io
> > project and potentially will mislead other DPDK consumer.
> 
> Why does FD.io code want to know which vector extension is used by burst routines?
> Is it going to share/preserve some resources (registers, etc.)? Is it robust ?
> Burst routines might not know whether vector extensions is used (they might call
> libraries, even rte_memcpy() can use vectors in implicit fashion).
> 

1.

The original issue description is:
"VPP uses dladdr() to translate a function address to name, however, some tx/rx functions
 in DPDK are invisible for dladdr(), which is because they are defined as static."

2.

So the RFC design is: one function, one description, like:
https://patchwork.dpdk.org/patch/57644/

	+#ifdef RTE_ARCH_X86
+	else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec_avx2)
+		len = snprintf(buf, sz, "AVX2 Vector Scattered Rx");
+	else if (dev->rx_pkt_burst == ice_recv_scattered_pkts_vec)
+		len = snprintf(buf, sz, "Vector Scattered Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts_vec_avx2)
+		len = snprintf(buf, sz, "AVX2 Vector Rx");
+	else if (dev->rx_pkt_burst == ice_recv_pkts_vec)
+		len = snprintf(buf, sz, "Vector Rx");
+#endif

3. Since the main issue is as Damjan replied in another thread:
   "people are reporting lower performance caused by DPDK deciding for variety
    of reasons to switch from vector PMD to scalar one."

   And Ferruh replied also:
    "As I understand this is to let applications to give informed decision based
     on what vectorization is used in the driver, currently this is not known by
     the application.
     
     And as previously replied, the main target of the API is to define the vector
     path, not all optimizations, so the number is limited."

     So we enhanced it with bit, example detail is (Yes, we defined a lit more,
     so we removed it in this patch):
       https://patchwork.dpdk.org/patch/61196/

4. And thanks Jerin's suggestion, I think his word can be more accurate: "This would
   help to reuse some of the flags to name conversion logic across all PMDs" for the
   reason we try to use bit to reduce some string format effort, it will be handled
   by the API internally "burst_mode_options_append(struct rte_eth_burst_mode *mode)".
   Now the new API will return the string finally:

#define RTE_ETH_BURST_MODE_ALT_OPT_SIZE 1024
struct rte_eth_burst_mode {
	uint64_t options;

	/**< Each PMD can fill specific burst mode information into this, and
	 * ethdev APIs will append the 'options' string format at its end.
	 */
	char alternate_options[RTE_ETH_BURST_MODE_ALT_OPT_SIZE];
};

So MLX PMD can add 'full_empw', 'mtsc_empw' etc into 'alternate_options' firstly, assign
'RTE_ETH_BURST_VECTOR | RTE_ETH_BURST_SSE' to 'options' as needed, then finally,
'alternate_options' will be "full_empw, Vector SSE".

Intel PMD can just assign "options", then finally, 'alternate_options' will be "Vector SSE".

How about the design idea ? Again, this 'options' is not to do standardization, just
want to reduce the duplicated name string things.

> With best regards, Slava
> 
> > Haiyue is working with Chenmin to address the issue and with your support it
> > will be even better.
> >
> > Your support will be highly appreciated!
> >
> > Thanks & Regards,
> > Yu Liu
> >
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Wang, Haiyue
> > Sent: Saturday, November 2, 2019 1:30 PM
> > To: Thomas Monjalon <thomas@monjalon.net>
> > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > <viacheslavo@mellanox.com>
> > Subject: Re: [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting
> > burst mode information
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Saturday, November 2, 2019 06:46
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: dev@dpdk.org; arybchenko@solarflare.com; Yigit, Ferruh
> > > <ferruh.yigit@intel.com>; jerinjacobk@gmail.com; Ye, Xiaolong
> > > <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>; Sun,
> > > Chenmin <chenmin.sun@intel.com>; Slava Ovsiienko
> > > <viacheslavo@mellanox.com>
> > > Subject: Re: [PATCH v1 3/3] ethdev: enhance the API for getting burst
> > > mode information
> > >
> > > Thank you for trying to address comments done late.
> > >
> > > 31/10/2019 18:11, Haiyue Wang:
> > > > --- a/lib/librte_ethdev/rte_ethdev.h
> > > > +++ b/lib/librte_ethdev/rte_ethdev.h
> >
> >
> > > > +#define RTE_ETH_BURST_ALTIVEC       (1ULL << 2)
> > > > +#define RTE_ETH_BURST_NEON          (1ULL << 3)
> > > > +#define RTE_ETH_BURST_SSE           (1ULL << 4)
> > > > +#define RTE_ETH_BURST_AVX2          (1ULL << 5)
> > > > +#define RTE_ETH_BURST_AVX512        (1ULL << 6)
> > >
> > > Of course, I still believe that giving a special treatment to vector
> > > instructions is wrong.
> > > You did not justify why it needs to be defined in bits instead of
> > > string. I am not asking again because anyway you don't really reply. I
> > > think you are executing an order you received and I don't want to
> > > blame you more.
> > > I suspect a real hidden issue in Intel CPUs that you try to mitigate.
> > > No need to reply to this comment.
> > > Anyway I will propose to replace this API in the next release.
> >
> > Never mind, if this design is truly ugly, drop it all now. I also prefer to do the
> > best, that's why open source is amazing, thanks! ;-)


  parent reply	other threads:[~2019-11-03  2:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 17:11 [dpdk-dev] [PATCH v1 1/3] net/ice: remove the specific burst mode bit set Haiyue Wang
2019-10-31 17:11 ` [dpdk-dev] [PATCH v1 2/3] net/i40e: " Haiyue Wang
2019-10-31 17:11 ` [dpdk-dev] [PATCH v1 3/3] ethdev: enhance the API for getting burst mode information Haiyue Wang
2019-11-01 22:46   ` Thomas Monjalon
2019-11-02  5:29     ` Wang, Haiyue
2019-11-02  6:55       ` Liu, Yu Y
2019-11-02  8:38         ` Slava Ovsiienko
2019-11-02 19:21           ` Damjan Marion (damarion)
2019-11-03  7:50             ` Slava Ovsiienko
2019-11-05 15:12               ` Ferruh Yigit
2019-11-05 15:54                 ` Stephen Hemminger
2019-11-03 20:46             ` Ray Kinsella
2019-11-03  2:34           ` Wang, Haiyue [this message]
2019-11-03  3:03             ` Wang, Haiyue
2019-11-03  8:59             ` Slava Ovsiienko
2019-11-03 11:38               ` Wang, Haiyue
2019-11-03 19:31                 ` Slava Ovsiienko
2019-11-04  1:01                   ` Wang, Haiyue
2019-11-02 18:31         ` Thomas Monjalon
2019-11-03  3:52     ` Wang, Haiyue
2019-11-03 22:20       ` Thomas Monjalon
2019-11-04  0:51         ` 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=E3B9F2FDCB65864C82CD632F23D8AB8773D8DE2D@shsmsx102.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=chenmin.sun@intel.com \
    --cc=damarion@cisco.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinjacobk@gmail.com \
    --cc=ray.kinsella@intel.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@mellanox.com \
    --cc=xiaolong.ye@intel.com \
    --cc=yu.y.liu@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).