From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <david.hunt@intel.com>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id 6195337B8
for <dev@dpdk.org>; Fri, 27 May 2016 11:52:45 +0200 (CEST)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
by fmsmga104.fm.intel.com with ESMTP; 27 May 2016 02:52:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.26,373,1459839600"; d="scan'208";a="815976801"
Received: from dhunt5-mobl.ger.corp.intel.com (HELO [10.237.220.26])
([10.237.220.26])
by orsmga003.jf.intel.com with ESMTP; 27 May 2016 02:52:42 -0700
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
References: <1460642270-8803-1-git-send-email-olivier.matz@6wind.com>
<1463665501-18325-1-git-send-email-david.hunt@intel.com>
<1463665501-18325-2-git-send-email-david.hunt@intel.com>
<20160524153509.GA11249@localhost.localdomain>
Cc: dev@dpdk.org, olivier.matz@6wind.com, yuanhan.liu@linux.intel.com,
pmatilai@redhat.com
From: "Hunt, David" <david.hunt@intel.com>
Message-ID: <574818EA.7010806@intel.com>
Date: Fri, 27 May 2016 10:52:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160524153509.GA11249@localhost.localdomain>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v5 1/3] mempool: support external handler
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2016 09:52:45 -0000
On 5/24/2016 4:35 PM, Jerin Jacob wrote:
> On Thu, May 19, 2016 at 02:44:59PM +0100, David Hunt wrote:
>> + /*
>> + * Since we have 4 combinations of the SP/SC/MP/MC examine the flags to
>> + * set the correct index into the handler table.
>> + */
>> + if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
>> + rte_mempool_set_handler(mp, "ring_sp_sc");
>> + else if (flags & MEMPOOL_F_SP_PUT)
>> + rte_mempool_set_handler(mp, "ring_sp_mc");
>> + else if (flags & MEMPOOL_F_SC_GET)
>> + rte_mempool_set_handler(mp, "ring_mp_sc");
>> + else
>> + rte_mempool_set_handler(mp, "ring_mp_mc");
> IMO, We should decouple the implementation specific flags of _a_
> external pool manager implementation from the generic rte_mempool_create_empty
> function as going further when we introduce new flags for custom HW accelerated
> external pool manager then this common code will be bloated.
These flags are only there to maintain backward compatibility for the
default handlers. I would not
envisage adding more flags to this, I would suggest just adding a new
handler using the new API calls.
So I would not see this code growing much in the future.
>> +/** Structure storing the table of registered handlers. */
>> +struct rte_mempool_handler_table {
>> + rte_spinlock_t sl; /**< Spinlock for add/delete. */
>> + uint32_t num_handlers; /**< Number of handlers in the table. */
>> + /** Storage for all possible handlers. */
>> + struct rte_mempool_handler handler[RTE_MEMPOOL_MAX_HANDLER_IDX];
>> +};
> add __rte_cache_aligned to this structure to avoid "handler" memory
> cacheline being shared with other variables
Will do.
>> +
>> +/** Array of registered handlers */
>> +extern struct rte_mempool_handler_table rte_mempool_handler_table;
>> +
>> +/**
>> + * @internal Get the mempool handler from its index.
>> + *
>> + * @param handler_idx
>> + * The index of the handler in the handler table. It must be a valid
>> + * index: (0 <= idx < num_handlers).
>> + * @return
>> + * The pointer to the handler in the table.
>> + */
>> +static struct rte_mempool_handler *
> inline?
Will do.
>> /* How many do we require i.e. number to fill the cache + the request */
>> - ret = rte_ring_mc_dequeue_bulk(mp->ring, &cache->objs[cache->len], req);
>> + ret = rte_mempool_ext_get_bulk(mp,
> This makes inline function to a function pointer. Nothing wrong in
> that. However, Do you see any performance drop with "local cache" only
> use case?
>
> http://dpdk.org/dev/patchwork/patch/12993/
With the latest mempool manager patch (without 12933), I see no
performance degradation on my Haswell machine.
However, when I apply patch 12933, I'm seeing a 200-300 kpps drop.
With 12933, the mempool_perf_autotest is showing 24% more
enqueues/dequeues, but testpmd forwarding
traffic between 2 40Gig interfaces from a hardware traffic generator
with one core doing the forwarding
is showing a drop of 200-300kpps.
Regards,
Dave.
---snip---