DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>, dpdk-dev <dev@dpdk.org>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Kinsella, Ray" <ray.kinsella@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	"Sun, Chenmin" <chenmin.sun@intel.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"Slava Ovsiienko" <viacheslavo@mellanox.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	David Marchand <david.marchand@redhat.com>,
	Jerin Jacob <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
Date: Tue, 29 Oct 2019 16:16:16 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB8773D8C4E9@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <CALBAE1MhCBgG+tGQfica46JrKgkt9rfJfYUWC-rDVLKmJzFGCA@mail.gmail.com>

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, October 29, 2019 23:59
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen Hemminger
> <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> 
> On Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Tuesday, October 29, 2019 22:09
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>; dpdk-dev
> > > <dev@dpdk.org>; Ye, Xiaolong <xiaolong.ye@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> > > Iremonger, Bernard <bernard.iremonger@intel.com>; Sun, Chenmin <chenmin.sun@intel.com>; Andrew
> > > Rybchenko <arybchenko@solarflare.com>; Slava Ovsiienko <viacheslavo@mellanox.com>; Stephen
> Hemminger
> > > <stephen@networkplumber.org>; David Marchand <david.marchand@redhat.com>; Jerin Jacob
> > > <jerinj@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information
> > >
> > > > > > >
> > > > > >
> > > > > > How about *_str_* style ?
> > > > >
> > > > > _name kind of implies it the string. may be _mode is good as it is short.
> > > > >
> > > > > > int
> > > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id,
> > > > > >                                       char *buf, int buflen)
> > > > >
> > > >
> > > > About the function, keep the same is better ? Then we need no whole
> > > > replace, just update the parameters, and the parameters indicated that
> > > > it is in string format.
> > >
> > > In this case, we need additional PMD op to get the buflen as
> > > the application will not know the buffer size in advance. It needs to come
> > > from the driver and common code.
> > >
> > >
> > > See below.
> > >
> > > >
> > > > > We don't need buflen as it is not known to the application. The
> > > > > typical pattern, we followed,
> > > > > in dpdk is, when function called buf as NULL then the function returns
> > > > > the expected size so that
> > > > > the application can alloc and get the buffer from ethdev layer on the
> > > > > next iteration.
> > > > >
> > > > >
> > > >
> > > > A little complicated and too heavy for using ? where is the example code ?
> > >
> > > See rte_eth_xstats_get_names() API as example for dynamic buffer allocation
> > > and similar use case in DPDK.
> >
> > In fact, this is no so complex as dynamic string handling. :)
> >
> >         /* Get count */
> >         cnt_xstats = rte_eth_xstats_get_names(port_id, NULL, 0);
> >         if (cnt_xstats  < 0) {
> >                 printf("Error: Cannot get count of xstats\n");
> >                 return;
> >         }
> >
> > xstats_names = malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats);
> >
> > struct rte_eth_xstat_name {
> >         char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */
> > };
> 
> 
> not really, it will be,[1]
> 
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, NULL);
> buf = malloc(count);
> count = rte_eth_rx_burst_mode_name(port_id, queue_id, buf);
> 
> 

I mean 'cnt_xstats' can be calculated like:
	count = RTE_NB_STATS;
	count += nb_rxqs * RTE_NB_RXQ_STATS;
	count += nb_txqs * RTE_NB_TXQ_STATS;

But for string, what I know is that use 'snprintf(NULL, 0, ...)' to get
the real length, in other words:
	1). NULL, call 'snprintf' to loop to get the length
	2). Not none, call 'sprint' to loop to dump into buffer.
 So in the function, have to handle two kind of loops.

And application has to handle memory allocation, free etc. Why not
just use a structure ? It is clean.

> >
> >
> > Frankly speaking, after re-thinking, I prefer to keep current design.
> > 1) Use the structure to expose the *raw* data. Make the APIs work as
> > a SDK, DON'T image to format the string for user. User can call the
> > API to dump to file, print to console etc. Because he has the raw
> > data.
> 
> [1] Dont have such issue.
> 
> >
> > struct rte_eth_burst_mode {
> >         uint64_t options;
> > };
> >
> > The 'options' bit definition reflects the rx/tx source code structure roughly:
> >
> > "tree drivers/net/ | grep rxtx"
> > │   ├── virtio_rxtx_simple_sse.c
> >     └── vmxnet3_rxtx.c
> 
> Files don't represent the actual mode PMD is running. So listing the
> file example is not correct.
> 

I mean the function in it.

> 
> >
> > 2. add "char dev_specific[]" data as needed if a PMD wants to expose it,
> >    enhance the APIs step by step, and do it as needed.
> 
> This would change ABI for no reason and who allocates the memory for
> dev_specific?

I mean like 'char dev_specific[128]', not zero length data. Sorry for confusion.


  reply	other threads:[~2019-10-29 16:16 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15  7:51 [dpdk-dev] [PATCH v4 0/4] get Rx/Tx packet " Haiyue Wang
2019-10-15  7:51 ` [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting " Haiyue Wang
2019-10-15 10:45   ` Ferruh Yigit
2019-10-15 11:23     ` Wang, Haiyue
2019-10-15 11:13   ` Ferruh Yigit
2019-10-25  9:36   ` Thomas Monjalon
2019-10-25 10:26     ` Jerin Jacob
2019-10-25 13:59     ` Wang, Haiyue
2019-10-25 14:08     ` Ferruh Yigit
2019-10-25 15:45       ` Thomas Monjalon
2019-10-25 16:02         ` Jerin Jacob
2019-10-25 22:27           ` Thomas Monjalon
2019-10-26  4:40             ` Wang, Haiyue
2019-10-26  6:24               ` Thomas Monjalon
2019-10-26  9:23                 ` Wang, Haiyue
2019-10-26 16:23                   ` Thomas Monjalon
2019-10-29 14:27                     ` Ferruh Yigit
2019-11-03 20:35                       ` Ray Kinsella
2019-11-03 22:41                         ` Thomas Monjalon
2019-11-04  9:49                           ` Ray Kinsella
2019-11-04  9:54                             ` Thomas Monjalon
2019-11-04 10:03                               ` Ray Kinsella
2019-11-04 10:46                                 ` Wang, Haiyue
2019-11-04 11:30                                 ` Thomas Monjalon
2019-11-04 12:07                                   ` Ray Kinsella
2019-11-04 13:09                                     ` Thomas Monjalon
2019-11-04 13:48                                       ` Ray Kinsella
2019-11-04 14:17                                         ` Wang, Haiyue
2019-10-26  6:40             ` Slava Ovsiienko
2019-10-26  9:31               ` Wang, Haiyue
2019-10-26  6:58             ` Jerin Jacob
2019-10-26  9:37               ` Wang, Haiyue
2019-10-29  3:37                 ` Jerin Jacob
2019-10-29  4:44                   ` Wang, Haiyue
2019-10-29  5:19                     ` Jerin Jacob
2019-10-29  5:42                       ` Wang, Haiyue
2019-10-29  5:47                         ` Jerin Jacob
2019-10-29  5:56                           ` Wang, Haiyue
2019-10-29  6:00                           ` Wang, Haiyue
2019-10-29  8:34                             ` Jerin Jacob
2019-10-29 11:26                               ` Wang, Haiyue
2019-10-29 12:56                                 ` Jerin Jacob
2019-10-29 13:51                                   ` Wang, Haiyue
2019-10-29 14:08                                     ` Jerin Jacob
2019-10-29 15:42                                       ` Wang, Haiyue
2019-10-29 15:59                                         ` Jerin Jacob
2019-10-29 16:16                                           ` Wang, Haiyue [this message]
2019-10-29 16:59               ` Ferruh Yigit
2019-10-30  4:38                 ` Jerin Jacob
2019-10-30  4:43                   ` Wang, Haiyue
2019-10-30  8:14                 ` Wang, Haiyue
2019-10-31 10:46                   ` Jerin Jacob
2019-10-31 11:15                     ` Ray Kinsella
2019-10-31 11:16                     ` Wang, Haiyue
2019-10-31 14:58                       ` Ferruh Yigit
2019-10-31 15:07                         ` Wang, Haiyue
2019-10-31 15:29                           ` Ferruh Yigit
2019-10-31 15:54                             ` Wang, Haiyue
2019-10-31 11:09                 ` Ray Kinsella
2019-10-15  7:51 ` [dpdk-dev] [PATCH v4 2/4] net/i40e: add Rx/Tx burst mode get callbacks Haiyue Wang
2019-10-15  7:51 ` [dpdk-dev] [PATCH v4 3/4] net/ice: " Haiyue Wang
2019-10-15  7:51 ` [dpdk-dev] [PATCH v4 4/4] app/testpmd: show the Rx/Tx burst mode description Haiyue Wang
2019-10-15 12:11 ` [dpdk-dev] [PATCH v4 0/4] get Rx/Tx packet burst mode information Ferruh Yigit

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=E3B9F2FDCB65864C82CD632F23D8AB8773D8C4E9@shsmsx102.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=bernard.iremonger@intel.com \
    --cc=chenmin.sun@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=ray.kinsella@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@mellanox.com \
    --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).