From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <knasim@sidebandnetworks.com>
Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com
 [209.85.218.46]) by dpdk.org (Postfix) with ESMTP id 31D143F9
 for <dev@dpdk.org>; Fri, 28 Nov 2014 18:34:52 +0100 (CET)
Received: by mail-oi0-f46.google.com with SMTP id h136so4891312oig.5
 for <dev@dpdk.org>; Fri, 28 Nov 2014 09:34:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=sidebandnetworks.com; s=google;
 h=mime-version:date:message-id:subject:from:to:cc:content-type;
 bh=1T07sovL+XhT9RuH52ggSQERkzimOnZuslub8MO2mrc=;
 b=dpNEceOC2zDEMM9sRyVDuPv3E/iQquXoPF1n235jrTo+/X0TSZKETDmMLuXaH6fi2A
 fVFgiLBn8EHjpl1oithCw3fZgQA8ETCi7sn02NqP2lykKrKpRal0GNUZTjSpVHvPFVgR
 B3KDFnIAjFBBnhJnAkQcnpyRMCQfFhOhavRvM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc
 :content-type;
 bh=1T07sovL+XhT9RuH52ggSQERkzimOnZuslub8MO2mrc=;
 b=OxpiCAM4pxqyLZ4M5m7vaz+k0MPZ6DCqHbsoIY4rhh5aAbAgDa2wvATUzqMH0gagJv
 tlL5oKECcfHwEhjl+mEaQC1sHj+HTg8cILp0CBlxfxMiLB61D2zxD4yepjhJZ/vxFxc5
 5SgyPV5kWEcWuUAls7l0vFzv1eKU79jDW+lQwxMmYBWII9V1y9ViJR0K6pF/O/fYj45a
 mUdZSmA+dAYFzGYYSzMWtqZSBXzouJ9ZZBu+7c9UwKBSqZK+OuOaKomve1NCZQCA/K1l
 HB1x5FMcH+0Hm75Pv7apgU7BrVYltluOsT7OjXfx5WGKKYvu5zHKV0kjuLgSlp+wgiZ6
 RtWg==
X-Gm-Message-State: ALoCoQm+Jqq415pONGeAMqlHoI0PBQQg2WVTKXo307/44a0i/m1BKdHG2IvNqCnGq8aZZ/ftvxXF
MIME-Version: 1.0
X-Received: by 10.202.212.82 with SMTP id l79mr26607726oig.12.1417196091485;
 Fri, 28 Nov 2014 09:34:51 -0800 (PST)
Received: by 10.202.48.79 with HTTP; Fri, 28 Nov 2014 09:34:51 -0800 (PST)
Date: Fri, 28 Nov 2014 12:34:51 -0500
Message-ID: <CAPrTskgmfxx=0hgnHBg=KMATTUhtp338vxESM=MMU6wTaW8SQQ@mail.gmail.com>
From: Kamraan Nasim <knasim@sidebandnetworks.com>
To: dev@dpdk.org
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: Steve Noble <snoble@sidebandnetworks.com>,
 Ashish Juneja <ajuneja@sidebandnetworks.com>
Subject: [dpdk-dev] RTE mempool "used count" steadily goes down to zero
 despite steady packet throughput
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, 28 Nov 2014 17:34:52 -0000

Hello,

I have ~15Gbps of traffic flowing through two 10GE ports and been profiling
the rte mempool(or rather the pktmbuf mempool) memory consumption:

I have per lcore caching disabled(cache_size is 0)

I have noticed that:
- Mempool FREE cnt(as given byt rte_mempool_free_count()) increases
- Mempool USED cnt(as given by rte_mempool_used_count() decreases and
eventually drops to 0. When this happens, mempool reports itself as EMPTY
- rx_nombuf stats for the eth ports start climbing
- Valgrind Memcheck does not indicate any obvious leaks in RTE mempool or
my application.


I was wondering if others have come across this issue?  Or if people here
have used ways, besides Valgrind to profile the mempool or the pkt mbuf
pool?

Thanks,
Kam