DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: Hemant Agrawal <hemant.agrawal@nxp.com>,
	Santosh Shukla <santosh.shukla@caviumnetworks.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/2] Allow application set mempool handle
Date: Fri, 30 Jun 2017 16:12:46 +0200	[thread overview]
Message-ID: <20170630161246.2af345e0@platinum> (raw)
In-Reply-To: <20170620140413.GA16157@jerin>

Hi,

On Tue, 20 Jun 2017 19:34:15 +0530, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> -----Original Message-----
> > Date: Tue, 20 Jun 2017 16:07:17 +0530
> > From: Hemant Agrawal <hemant.agrawal@nxp.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > CC: Santosh Shukla <santosh.shukla@caviumnetworks.com>,
> >  olivier.matz@6wind.com, dev@dpdk.org
> > Subject: Re: [PATCH 0/2] Allow application set mempool handle
> > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> >  Thunderbird/45.8.0
> > 
> > On 6/19/2017 6:31 PM, Jerin Jacob wrote:  
> > > -----Original Message-----  
> > > > Date: Mon, 19 Jun 2017 17:22:46 +0530
> > > > From: Hemant Agrawal <hemant.agrawal@nxp.com>
> > > > To: Santosh Shukla <santosh.shukla@caviumnetworks.com>,
> > > >  olivier.matz@6wind.com, dev@dpdk.org
> > > > CC: jerin.jacob@caviumnetworks.com
> > > > Subject: Re: [PATCH 0/2] Allow application set mempool handle
> > > > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
> > > >  Thunderbird/45.8.0
> > > > 
> > > > On 6/1/2017 1:35 PM, Santosh Shukla wrote:  
> > > > > Some platform can have two different NICs for example external PCI Intel
> > > > > 40G card and Integrated NIC like vNIC/octeontx/dpaa2.
> > > > > 
> > > > > Both NICs like to use their preferred pool e.g. external PCI card/ vNIC's
> > > > > preferred pool would be the ring based pool and octeontx/dpaa2 preferred would
> > > > > be ext-mempools.
> > > > > Right now, Framework doesn't support such case. Only one pool can be
> > > > > used across two different NIC's. For that, user has to statically set
> > > > > CONFIG_RTE_MEMPOOL_DEFAULT_OPS=<pool-name>.
> > > > > 
> > > > > So proposing two approaches:
> > > > > Patch 1) Introducing eal option --pkt-mempool=<pool-name>
> > > > > Patch 2) Introducing ethdev API called _get_preferred_pool(), where PMD driver
> > > > > gets a chance to advertise their pool capability to the application. And based
> > > > > on that hint- application creates pools for that driver.  
> > 
> > If the system is having more than one heterogeneous ethernet device with
> > different mempool, the application has to create different mempool for each
> > of the ethernet device.
> > 
> > However, let's take a case
> > As system has a DPAA2 eth device, which only work with dpaa2 mempools.  
> 
> dpaa2 ethdev will return dpaa2 mempool as preferred handler.
> 
> > System also detect a standard PCI NIC, which can work with any software
> > mempool (e.g ring_mp_mc) or with dpaa2 mempool. Given the preference, PCI
> > NIC will have preferred as software mempool.
> > how the application will choose between these, if it want to create only one
> > mempool?  
> 
> We need add some policy in common code to help application to choose
> in case if application interested in creating in one pool for
> heterogeneous cases. It is more of application problem, ethdev can
> return the preferred handler, let application choose interested in one.
> ethdev is depended on the specific mempool not any other object.
> 
> We will provide option 1(eal argument based one) as one policy.More sophisticated
> policies we need add in application.
> 
> 
> > Or, how the scheme will work if the application want to create only one
> > mempool?  
> 
> option 1 (eal argument based) or we need to change the application to
> choose from available ethdev count and its preferred mempool handler.

I also think the approach in this patchset is not that bad:

- The first step is to allow the user to specify the mempool
  dynamically (eal arg).

  One thing I don't really like is to have a mempool-related argument
  inside eal. It would be better if eal could provide a framework so
  that each libraries (ex: mbuf, mempool) can register their argument
  that could be changed through the command line or trough an API.

  Without this, it introduces a sort of dependency between eal and
  mempool, which I don't think is sane.

- The second step is to be able to ask to the eth devices which
  mempool they prefer. If there is only one kind of port, it's
  quite easy.

  As suggested, more complexity could go in the application if
  required, or some helpers could be provided in the future.


I'm sending some comments as replies to the patches.

  reply	other threads:[~2017-06-30 14:12 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01  8:05 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
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 [this message]
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=20170630161246.2af345e0@platinum \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.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).