All of lore.kernel.org
 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 [dpdk-dev] [PATCH v2] ethdev: enhance the API for getting burst mode information 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.