From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 57AFA432BC;
	Mon,  6 Nov 2023 20:24:40 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 46EF7402BA;
	Mon,  6 Nov 2023 20:24:40 +0100 (CET)
Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com
 [209.85.215.176])
 by mails.dpdk.org (Postfix) with ESMTP id 41967402B6
 for <dev@dpdk.org>; Mon,  6 Nov 2023 20:24:39 +0100 (CET)
Received: by mail-pg1-f176.google.com with SMTP id
 41be03b00d2f7-5bcf83a8f6cso3709632a12.2
 for <dev@dpdk.org>; Mon, 06 Nov 2023 11:24:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1699298678;
 x=1699903478; darn=dpdk.org; 
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=t88krfztedD7bOZqM99zQwIlGfnBHIWS5aMPuRUIlXM=;
 b=2mLNqeuVwWJELC1N2BR+Ne2TZGpAT4YirePjOmv5HEcw6XZrY4h9DeXRhEknejzKCi
 fmwYehRmNAalJUD2E4BACV5MlURg5uK16vbBQAlMzgU+FqWYGzIhdNQ9LC0RCNkHj3D2
 fhCjJGWeHAylPBGSN0jSZh+dWCUyb5uC//obAnRaeKZJkafY3DF38YwBY6lIV8Qw/C/U
 O1AoQpuz7fFimv8z0R/T9e4wANjNd7nclSaVEuoWp86abvDm+gyr4mnaDDDIhX89ImRZ
 Bi1Fr28y/jUtnpAzxRqne40Qbuulrm2zjVC6PYrF3j2miSwtChnpWxzwLCXswueIMOwF
 vfRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1699298678; x=1699903478;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=t88krfztedD7bOZqM99zQwIlGfnBHIWS5aMPuRUIlXM=;
 b=OViddFRlQ1iyND/06xbtrcmk3tvL4dKaIVHfppy1U1YyhRbD9hjBdEGMkvDXyx0Rt+
 yxfDy0tAVqIOMomGQNkdFplxfgfgBqLzmBfs4JbPtyjn9zxHZjz4/10u2+9OiNmwx4Zg
 wBaxcSZr7nUFqtZ44KKTRGOZSo/TFLoq3qlped6DiFQUR/By/jTAOm/loH841PLD1eWy
 ZmtxR9TziBUu93qUVX9Nb/+thYmw2fFIV9yaZxSSCjPKt88YU31caZtmZOv0htuINR8B
 AnixtdL+nKTnxBoCWb0SPOpCvwqqUk4EMTzQ58bL75xVpoEwqm4Fhd1GKV/6XiLKrjnV
 LvKw==
X-Gm-Message-State: AOJu0YzqSnbtZuRC6YE7Carxq3y1xQuS9Hs6CnF3SqDo9ql2hUzropOY
 tb0hoVCHvYnDN/0Yb2VXMtgBsw==
X-Google-Smtp-Source: AGHT+IHDCri5fJwZGOSh1DaCBYmN5FnBkhyZMUJAABuqsjQM92zwXC91BRVveQ2/WcRZw1j1Z8k0aw==
X-Received: by 2002:a17:90a:3ea5:b0:280:c316:63e1 with SMTP id
 k34-20020a17090a3ea500b00280c31663e1mr13117630pjc.41.1699298678334; 
 Mon, 06 Nov 2023 11:24:38 -0800 (PST)
Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141])
 by smtp.gmail.com with ESMTPSA id
 fw11-20020a17090b128b00b00268b439a0cbsm5708929pjb.23.2023.11.06.11.24.37
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 06 Nov 2023 11:24:38 -0800 (PST)
Date: Mon, 6 Nov 2023 11:24:36 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, Morten =?UTF-8?B?QnLDuHJ1cA==?= <mb@smartsharesystems.com>
Subject: Re: [PATCH] dumpcap: fix mbuf pool ring type
Message-ID: <20231106112436.74d672f6@hermes.local>
In-Reply-To: <CAJFAV8yktcK4DZXCYeLnsJ==tEWvD3y=uS9rZFZX=HjZHdEvnQ@mail.gmail.com>
References: <20230804161604.61050-1-stephen@networkplumber.org>
 <CAJFAV8yktcK4DZXCYeLnsJ==tEWvD3y=uS9rZFZX=HjZHdEvnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Mon, 2 Oct 2023 09:33:50 +0200
David Marchand <david.marchand@redhat.com> wrote:

> Switching to rte_pktmbuf_pool_create() still leaves the user with the
> possibility to shoot himself in the foot (I was thinking of setting
> some --mbuf-pool-ops-name EAL option).
> 
> This application has explicit requirements in terms of concurrent
> access (and I don't think the mempool library exposes per driver
> capabilities in that regard).
> The application was enforcing the use of mempool/ring so far.
> 
> I think it is safer to go with an explicit
> rte_pktmbuf_pool_create_by_ops(... "ring_mp_mc").
> WDYT?

The dumpcap command does not have EAL command line arguments that can
be changed by user.