From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ken.schumm@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id B9D536829
 for <dev@dpdk.org>; Tue, 17 Dec 2013 19:15:54 +0100 (CET)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga101.jf.intel.com with ESMTP; 17 Dec 2013 10:16:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.95,502,1384329600"; 
 d="scan'208,217";a="426158405"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129])
 by orsmga001.jf.intel.com with ESMTP; 17 Dec 2013 10:13:36 -0800
Received: from orsmsx103.amr.corp.intel.com ([169.254.2.114]) by
 ORSMSX102.amr.corp.intel.com ([169.254.1.112]) with mapi id 14.03.0123.003;
 Tue, 17 Dec 2013 10:13:36 -0800
From: "Schumm, Ken" <ken.schumm@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: When are mbufs released back to the mempool?
Thread-Index: Ac77U7KrHCnCMBiYSBelk4UK5b93tg==
Date: Tue, 17 Dec 2013 18:13:35 +0000
Message-ID: <B35F7300EA51774C974164D11E30E3E42DFA11EB@ORSMSX103.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [dpdk-dev] When are mbufs released back to the mempool?
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: Tue, 17 Dec 2013 18:15:55 -0000

When running l2fwd the number of available mbufs returned by rte_mempool_co=
unt() starts at 7680 on an idle system.

As traffic commences the count declines from 7680 to 5632 (expected).

When traffic stops the count does not climb back to the starting value, ind=
icating that idle mbufs are not returned to the mempool.

For the LCORE cache the doc states

"While this may mean a number of buffers may sit idle on some core's cache,=
 the speed
at which a core can access its own cache for a specific memory pool without=
 locks
provides performance gains"

which makes sense.

Is this also true of ring buffers?

We need to understand when packets are released back to the mempool and wit=
h l2fwd it appears that they never are, at least not all of them.

Thanks!