DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Wang, Haiyue" <haiyue.wang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"viacheslavo@mellanox.com" <viacheslavo@mellanox.com>,
	"damarion@cisco.com" <damarion@cisco.com>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Sun, Chenmin" <chenmin.sun@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	"Liu, Yu Y" <yu.y.liu@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: enhance the API for getting burst mode information
Date: Wed, 06 Nov 2019 09:19:32 +0100	[thread overview]
Message-ID: <3663289.PNCOYS1eAT@xps> (raw)
In-Reply-To: <E3B9F2FDCB65864C82CD632F23D8AB8773D8EE9E@shsmsx102.ccr.corp.intel.com>

06/11/2019 02:21, Wang, Haiyue:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 04/11/2019 11:39, Haiyue Wang:
> > >  /**
> > >   * Ethernet device RX/TX queue packet burst mode information structure.
> > >   * Used to retrieve information about packet burst mode setting.
> > >   */
> > >  struct rte_eth_burst_mode {
> > > -	uint64_t options;
> > > +	uint64_t flags; /**< The ORed values of RTE_ETH_BURST_FLAG_xxx */
> > > +
> > > +#define RTE_ETH_BURST_MODE_INFO_SIZE 1024 /**< Maximum size for information */
> > > +	char info[RTE_ETH_BURST_MODE_INFO_SIZE]; /**< burst mode information */
> > >  };
> > 
> > I think the API can be simpler by passing the flags as function parameter.
> > 
> > In my understanding the burst mode name is fixed per Rx/Tx function,
> > so it can be a constant string referenced with a simple char*.
> > 
> > This is the current API:
> > 
> > int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> >     struct rte_eth_burst_mode *mode);
> > 
> > I wonder what do you think of such API? (just a proposal for comments):
> > 
> > char *rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id, uint64_t flags);
> > 
> > Or is there some cases where you want to build the string with snprintf?
> > (I cannot think about a case, given it should mapped to a C-function)
> > 
> 
> 1. 'a constant string' is hard for PMD expanding if it wants to make the string
>    dynamic according to the setting, like: http://patchwork.dpdk.org/patch/62352/
>    (although based on bit options design).

Yes, constant string is less flexible in the PMD implementation.

> 2. And for dynamic string, if it is *return type*, then the PMD needs to
>    handle the memory allocation, and the application frees it. And 'uint64_t flags'
>    is output parameter, so it should be like 'uint64_t *flags', but this needs the
>    application to declare it or not, and needs PMDs to check whether it is passed
>    or not, then set it.
> 
>    So for making things easy, the 'struct rte_eth_burst_mode' may be nice, then the
>    application just declares one line : 'struct rte_eth_burst_mode mode', then all
>    things are filled by PMD in one place.

I agree it is a lot simpler to use a struct.



  parent reply	other threads:[~2019-11-06  8:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-04 10:39 Haiyue Wang
2019-11-05 15:51 ` Ray Kinsella
2019-11-06  0:33 ` Thomas Monjalon
2019-11-06  1:21   ` Wang, Haiyue
2019-11-06  1:40     ` Wang, Haiyue
2019-11-06  8:19     ` Thomas Monjalon [this message]
2019-11-06  1:30 ` [dpdk-dev] [PATCH v3] " Haiyue Wang
2019-11-06  9:19   ` Thomas Monjalon
2019-11-06 10:49     ` Wang, Haiyue
2019-11-06 15:13       ` Ferruh Yigit
2019-11-06  9:36   ` Slava Ovsiienko

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=3663289.PNCOYS1eAT@xps \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=chenmin.sun@intel.com \
    --cc=damarion@cisco.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=jerinjacobk@gmail.com \
    --cc=ray.kinsella@intel.com \
    --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).