DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: santosh <santosh.shukla@caviumnetworks.com>,
	dev@dpdk.org, hemant.agrawal@nxp.com
Subject: Re: [dpdk-dev] [PATCH 2/2] ether/ethdev: Allow pmd to advertise preferred pool capability
Date: Tue, 4 Jul 2017 19:42:25 +0530	[thread overview]
Message-ID: <20170704141224.GA25978@jerin> (raw)
In-Reply-To: <20170704150714.4feaa396@platinum>

-----Original Message-----
> Date: Tue, 4 Jul 2017 15:07:14 +0200
> From: Olivier Matz <olivier.matz@6wind.com>
> To: santosh <santosh.shukla@caviumnetworks.com>
> Cc: dev@dpdk.org, hemant.agrawal@nxp.com, jerin.jacob@caviumnetworks.com
> Subject: Re: [PATCH 2/2] ether/ethdev: Allow pmd to advertise preferred
>  pool capability
> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
> 
> On Tue, 4 Jul 2017 18:09:33 +0530, santosh <santosh.shukla@caviumnetworks.com> wrote:
> > On Friday 30 June 2017 07:43 PM, Olivier Matz wrote:

Hi Olivier,

> > 
> > >> +
> > >> +int
> > >> +rte_eth_dev_get_preferred_pool(uint8_t port_id, const char *pool)
> > >> +{
> > >> +	struct rte_eth_dev *dev;
> > >> +
> > >> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > >> +
> > >> +	dev = &rte_eth_devices[port_id];
> > >> +
> > >> +	if (*dev->dev_ops->get_preferred_pool == NULL) {
> > >> +		pool = RTE_MBUF_DEFAULT_MEMPOOL_OPS;
> > >> +		return 0;
> > >> +	}
> > >> +	return (*dev->dev_ops->get_preferred_pool)(dev, pool);
> > >> +}  
> > > Instead of this, what about:
> > >
> > > /*
> > >  * Return values:
> > >  *   - -ENOTSUP: error, pool type is not supported
> > >  *   - on success, return the priority of the mempool (0 = highest)
> > >  */
> > > int
> > > rte_eth_dev_pool_ops_supported(uint8_t port_id, const char *pool)
> > >
> > > By default, always return 0 (i.e. all pools are supported).
> > >
> > > With this API, we can announce several supported pools (not only
> > > one preferred), and order them by preference.  
> > 
> > IMO: We should let application to decide on pool preference. Driver
> > only to advice his preferred or supported pool handle to application,
> > and its upto application to decide on pool selection scheme. 
> 
> The api I'm proposing does not prevent the application from taking
> the decision. On the contrary, it gives more clues to the application:
> an ordered list of supported pools, instead of just the preferred pool.

Does it complicate the mempool selection procedure from the application
perspective? I have a real world use case, We can take this as a base for
for brainstorming.

A system with two ethdev ports
- Port 0 # traditional NIC # Preferred mempool handler: ring
- Port 1 # integrated NIC # Preferred mempool handler: a_HW_based_ring

Some of the characteristics of HW based ring:
- TX buffer recycling done by HW(packet allocation and free done by HW
  no software intervention is required)
- It will _not_ be fast when using it with traditional NIC as traditional NIC does
packet alloc and free using SW which comes through mempool per cpu caches unlike
HW ring solution.
- So an integrated NIC with a HW based ring does not really make sense
  to use SW ring handler and other way around too.

So in this context, All application wants to know the preferred handler
for the given ethdev port and any other non preferred handlers are _equally_ bad.
Not sure what would be preference for taking one or another if  _the_ preferred
handler attached not available to the integrated NIC.

>From application perspective,
approach 1:

char pref_mempool[128];
rte_eth_dev_pool_ops_supported(ethdev_port_id, pref_mempool /* out */);
create_mempool_by_name(pref_mempool);
eth_dev_rx_configure(pref_mempool);


approach 2 is very complicated. The first problem is API to get the available
pools. Unlike ethdev, mempool uses compiler based constructor scheme to
register the mempool PMD and normal build will have all the mempool PMD
even though it is not used or applicable.
Isn't complicating external mempool usage from application perspective?

If there any real world use for giving a set of pools for a given
eth port then it make sense to add the complication in the application.
Does any one has such _real world_ use case ?

/Jerin

  reply	other threads:[~2017-07-04 14:12 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  8:05 [dpdk-dev] [PATCH 0/2] Allow application set mempool handle Santosh Shukla
2017-06-01  8:05 ` [dpdk-dev] [PATCH 1/2] eal: Introducing option to " Santosh Shukla
2017-06-30 14:12   ` Olivier Matz
2017-07-04 12:33     ` santosh
2017-06-01  8:05 ` [dpdk-dev] [PATCH 2/2] ether/ethdev: Allow pmd to advertise preferred pool capability Santosh Shukla
2017-06-30 14:13   ` Olivier Matz
2017-07-04 12:39     ` santosh
2017-07-04 13:07       ` Olivier Matz
2017-07-04 14:12         ` Jerin Jacob [this message]
2017-06-19 11:52 ` [dpdk-dev] [PATCH 0/2] Allow application set mempool handle Hemant Agrawal
2017-06-19 13:01   ` Jerin Jacob
2017-06-20 10:37     ` Hemant Agrawal
2017-06-20 14:04       ` Jerin Jacob
2017-06-30 14:12         ` Olivier Matz
2017-07-04 12:25           ` santosh
2017-07-04 15:59             ` Olivier Matz
2017-07-05  7:48               ` santosh
2017-07-20  7:06 ` [dpdk-dev] [PATCH v2 0/2] Dynamically configure " Santosh Shukla
2017-07-20  7:06   ` [dpdk-dev] [PATCH v2 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-08-15  8:07     ` [dpdk-dev] [PATCH v3 0/2] Dynamically configure mempool handle Santosh Shukla
2017-08-15  8:07       ` [dpdk-dev] [PATCH v3 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-09-04 11:46         ` Olivier MATZ
2017-09-07  9:25         ` Hemant Agrawal
2017-08-15  8:07       ` [dpdk-dev] [PATCH v3 2/2] ethdev: allow pmd to advertise " Santosh Shukla
2017-09-04 12:11         ` Olivier MATZ
2017-09-04 13:14           ` santosh
2017-09-07  9:21             ` Hemant Agrawal
2017-09-07 10:06               ` santosh
2017-09-07 10:11                 ` santosh
2017-09-07 11:08                   ` Hemant Agrawal
2017-09-11  9:33                     ` Olivier MATZ
2017-09-11 12:40                       ` santosh
2017-09-11 13:00                         ` Olivier MATZ
2017-09-04  9:41       ` [dpdk-dev] [PATCH v3 0/2] Dynamically configure mempool handle Sergio Gonzalez Monroy
2017-09-04 13:20         ` santosh
2017-09-04 13:34         ` Olivier MATZ
2017-09-04 14:24           ` Sergio Gonzalez Monroy
2017-09-05  7:47             ` Olivier MATZ
2017-09-05  8:11               ` Jerin Jacob
2017-09-11 15:18       ` [dpdk-dev] [PATCH v4 " Santosh Shukla
2017-09-11 15:18         ` [dpdk-dev] [PATCH v4 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-09-25  7:28           ` Olivier MATZ
2017-09-25 21:23             ` santosh
2017-09-11 15:18         ` [dpdk-dev] [PATCH v4 2/2] ethdev: get the supported pools for a port Santosh Shukla
2017-09-25  7:37           ` Olivier MATZ
2017-09-25 21:52             ` santosh
2017-09-29  5:00               ` santosh
2017-09-29  8:32               ` Olivier MATZ
2017-09-29 10:16                 ` santosh
2017-09-29 11:21                   ` santosh
2017-09-29 11:23                   ` Olivier MATZ
2017-09-29 11:31                     ` santosh
2017-09-13 10:00         ` [dpdk-dev] [PATCH v4 0/2] Dynamically configure mempool handle santosh
2017-09-19  8:28           ` santosh
2017-09-25  7:24             ` Olivier MATZ
2017-09-25 21:58               ` santosh
2017-10-01  9:14         ` [dpdk-dev] [PATCH v5 " Santosh Shukla
2017-10-01  9:14           ` [dpdk-dev] [PATCH v5 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-10-02 14:29             ` Olivier MATZ
2017-10-06  0:29             ` Thomas Monjalon
2017-10-06  3:31               ` santosh
2017-10-06  8:39                 ` Thomas Monjalon
2017-10-06  7:45             ` [dpdk-dev] [PATCH v6 0/2] Dynamically configure mempool handle Santosh Shukla
2017-10-06  7:45               ` [dpdk-dev] [PATCH v6 1/2] eal: allow user to override default pool handle Santosh Shukla
2017-10-06  7:45               ` [dpdk-dev] [PATCH v6 2/2] ethdev: get the supported pool for a port Santosh Shukla
2017-10-06 18:58               ` [dpdk-dev] [PATCH v6 0/2] Dynamically configure mempool handle Thomas Monjalon
2017-10-01  9:14           ` [dpdk-dev] [PATCH v5 2/2] ethdev: get the supported pool for a port Santosh Shukla
2017-10-02 14:31             ` Olivier MATZ
2017-10-06  0:30             ` Thomas Monjalon
2017-10-06  3:32               ` santosh
2017-10-02  8:37           ` [dpdk-dev] [PATCH v5 0/2] Dynamically configure mempool handle santosh
2017-07-20  7:06   ` [dpdk-dev] [PATCH v2 2/2] ethdev: allow pmd to advertise pool handle Santosh Shukla

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=20170704141224.GA25978@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=olivier.matz@6wind.com \
    --cc=santosh.shukla@caviumnetworks.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).