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 D5B17432BF; Tue, 7 Nov 2023 03:36:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4CB5402B5; Tue, 7 Nov 2023 03:36:22 +0100 (CET) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by mails.dpdk.org (Postfix) with ESMTP id 58DFD402A1 for ; Tue, 7 Nov 2023 03:36:21 +0100 (CET) Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-6ce322b62aeso3244108a34.3 for ; Mon, 06 Nov 2023 18:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1699324580; x=1699929380; 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=otb48lsMlnsf5SiQyp5tt5umx6Vn5tDhxFXiNG/B/AY=; b=a6RPwuqRgKRpH4koYNPD3TuqacqZCtERgtaa5EsFLNpBC2ApHGltfeRDWBBNmAx0SW 0r5SoJmAzJgkLNKnR5BB3WyBkBUh01FPMMjKF5PP5ohtGa3tgnZNOA6PoJtyyg+t4o6H +Iv6TGPAK6HH5lcoWzeY7lazymzRQeBQcQUJHBG61h9xS6c5DeStuQyPYPcfq5vwSlik w1YDyyL9BaOdLlFAqKTh3yDlv0k/8n6QEcEWuaq06ZdzZlylwNVJ63x3rI7mKxkn/TVl Uf2jWFPE6PcTPyNT3B5IwVeQQJiJdTUjuC/iQXpfE4mySs0mu5RaNpPeqoejS8Hw3JJ3 TBHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699324580; x=1699929380; 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=otb48lsMlnsf5SiQyp5tt5umx6Vn5tDhxFXiNG/B/AY=; b=cV2Ooynbm9srYvAqIz039cFuoA4oCetyzLiVEax30DemsTRJ8yrh7du+p64lfXCwJx CHUwhjBBOKa5raEChEYYL+nPHCSMO/JcDt5TjQ1/ZJS6Qxu3CYOnydBC4U4CazPaPnCq Fpa/43uJgXCqV1JNC70QRdtm+F4r99JcuMmIRzuMCYpjkeI7aYPiiBc7p0KCr+8jwDjE 3CK3UpKKxyQKE5pmhnAvuZ+PKqFuE/rG9E9aYkQBSLK+lsL2ZGrsknYzuLijF0UkNtSP gXtBQQI6m2Zb/UJYR6vI3w2O+h0hAp8p+ISVYGny9HbKrog/R0D/tmfHH1xL9DBWMOlh aCVA== X-Gm-Message-State: AOJu0YxdZ0QDaM8YLUWodali1Qbf5JgvANG8Zp+IHbV/6iWPsO9J27v5 02esc3uULcPH0f6OY5Y2smyaCw== X-Google-Smtp-Source: AGHT+IFN2+4QM2J4wpbMd3xw+ZECOMM/miapQCVTKLJw031Xu/C0Vbn3lZj+b2WB5+s1xOISNn8tRw== X-Received: by 2002:a05:6830:20ce:b0:6bd:836:4fc2 with SMTP id z14-20020a05683020ce00b006bd08364fc2mr33474169otq.17.1699324580510; Mon, 06 Nov 2023 18:36:20 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id q17-20020a056a00085100b00693411c6c3csm6185882pfk.39.2023.11.06.18.36.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 18:36:20 -0800 (PST) Date: Mon, 6 Nov 2023 18:36:18 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "David Marchand" , , Subject: Re: [PATCH] dumpcap: fix mbuf pool ring type Message-ID: <20231106183618.79ab6f93@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFE6@smartserver.smartshare.dk> References: <20230804161604.61050-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35D87C27@smartserver.smartshare.dk> <20231106112331.690cc454@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9EFE6@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, 6 Nov 2023 22:50:50 +0100 Morten Br=C3=B8rup wrote: > > > And I guess there might be other use cases than this one, where a =20 > > thread-safe mempool driver is required. So adding a generalized > > function to get the "upgraded" (i.e. thread safe) variant of a mempool > > driver would be nice. =20 > > > =20 > >=20 > > If the user overrides the default mbuf pool type, then it will need to > > be thread safe for > > the general case of driver as well (or they are on single cpu). =20 >=20 > If they have chosen a thread safe pool type, using the chosen type will w= ork for dumpcap too. I think we all agree on that. >=20 > I'm not sure I understand your single-cpu argument, so let me try to para= phrase: >=20 > If their application only uses one EAL thread, and they have chosen "ring= _sc_sp", dumpcap also work, because mempool accesses are still single-threa= ded. Is this correctly understood? >=20 > Or are you saying that if they want to use dumpcap, they must choose a th= read safe pool type for their application (regardless if the application is= single-threaded or not)? There is no command line of EAL nature in dumpcap. This is intentional. QED: overriding default pool type is not going to be a possible