From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 49C7B432BC; Mon, 6 Nov 2023 20:23:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1B55F402BA; Mon, 6 Nov 2023 20:23:36 +0100 (CET) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by mails.dpdk.org (Postfix) with ESMTP id 746B2402B6 for ; Mon, 6 Nov 2023 20:23:35 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1cc68c1fac2so44438045ad.0 for ; Mon, 06 Nov 2023 11:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1699298614; x=1699903414; 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=QhSQbeto51Yp/5hbo5rC9T7Ymq7nMWcUTzHyDrKzj2M=; b=gPkUVFa/WqXC/TeOwM8fPK1gC2SKLeBHxYZ6X8wp33xCtAT91t9gJssTjD3UoOachi 0clBs6Ja4BDG9SyNT9545Has3q3YkDke6stKlm1Zk2/5scD6WrGX0yAyMVZ7fsGF8fFn KRAAVGTh1EQmTWMslJPgcFShP/aKaQlIZkMrjUA92mptpnmedjR26+GEap5PRBobXV8o vXVom0uvR/nrcsrNI97Q2xiRV/XsNnwK4Qa61Pqd4TGieQ4ylCJeUNBeKBbnizHNRFHf XoUo54hbbEiBrb//XlaPefp6AXepexr7SaDw051nJlv+4x2eqX+LDGXadxlt+qfXrJQg uMaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699298614; x=1699903414; 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=QhSQbeto51Yp/5hbo5rC9T7Ymq7nMWcUTzHyDrKzj2M=; b=vzwln1MnEf/xkkKFdRtCHfmAWQIA/CrMweCMgvmkjj2Y+82c3QZzLhdh+zg7x9kErl U9iEb+arW/TAf+bTaICZD9GSLOtgc8nYoZEWJv6IeOgEqcTBOgQQ0yLQvzOAyuW0wl1x LgPp07HT4dKfVumKl0Htc9qWDszza4EGoND6MOvK4A05eH5iJe0yHVjh8vg/LgY91oAJ AUZxU3BkRF32+S87sRmdxTr7g5ZETuWG95nBKWp+tr60PZhTIsCtjL5w7ZxfpwTCUgP1 9Udlu1fP5wqwdYi/inLH5tbwwGV+QXGEmnn/GgeOuOcN58tLMiXyUowxkmaKb5jeulT5 6hSg== X-Gm-Message-State: AOJu0YxzZ4AxMER+R1S5KMd5Q1jQra9FWY8XodJHgbvstJUkyw9MIbKO WhR9YE2g/BsWjtgUFk/nmoS0VA== X-Google-Smtp-Source: AGHT+IEjVneNZc1Z+9EtgfLd43BaLJzTTj939XZVGdul7FLH2dARkoPRfN4YdfZ5doRdlf9ib/UHRQ== X-Received: by 2002:a17:902:fa85:b0:1cc:4467:a563 with SMTP id lc5-20020a170902fa8500b001cc4467a563mr21134124plb.3.1699298614462; Mon, 06 Nov 2023 11:23:34 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id jc4-20020a17090325c400b001c613091aeesm6198393plb.293.2023.11.06.11.23.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 11:23:34 -0800 (PST) Date: Mon, 6 Nov 2023 11:23:31 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "David Marchand" , , Subject: Re: [PATCH] dumpcap: fix mbuf pool ring type Message-ID: <20231106112331.690cc454@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87C27@smartserver.smartshare.dk> References: <20230804161604.61050-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35D87C27@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 2 Oct 2023 10:42:53 +0200 Morten Br=C3=B8rup 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). > >=20 > > 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. > >=20 > > I think it is safer to go with an explicit > > rte_pktmbuf_pool_create_by_ops(... "ring_mp_mc"). > > WDYT? =20 >=20 > > Or perhaps one of "ring_mt_rts" or "ring_mt_hts", if any of those mbuf po= ol drivers are specified on the command line; otherwise fall back to "ring_= mp_mc". >=20 > Actually, I prefer Stephen's suggestion of using the default mbuf pool dr= iver. The option is there for a reason. >=20 > However, David is right: We want to prevent the user from using a thread-= unsafe mempool driver in this use case. >=20 > And I guess there might be other use cases than this one, where a thread-= safe mempool driver is required. So adding a generalized function to get th= e "upgraded" (i.e. thread safe) variant of a mempool driver would be nice. > If the user overrides the default mbuf pool type, then it will need to be t= hread safe for the general case of driver as well (or they are on single cpu).=20 I think the patch should be applied as is.