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 24728A0093 for ; Mon, 28 Nov 2022 18:16:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9DD344067E; Mon, 28 Nov 2022 18:16:49 +0100 (CET) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by mails.dpdk.org (Postfix) with ESMTP id 03E9E40150 for ; Mon, 28 Nov 2022 18:16:47 +0100 (CET) Received: by mail-pl1-f177.google.com with SMTP id d6so10799281pll.7 for ; Mon, 28 Nov 2022 09:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; 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=VyuytHmYOae+USwA1IdG+NGC5LfZPVWqslDgM4A+QUk=; b=KE6fppl/p8wz6o3S8YtzIPfmJ+nNEMJcRXpwZvgseCgpTdVxtIBV5Ea2ba0DxJBm5H VjovV8D9UjhPyDc4FIfv5jdmhKwhY2QcIFpUj26R4sRUuKK8Y0U+FWZjJXXlLJqQDGFp 5aSUppx11YdZKVIf6SrynoeIPCJhs7J22+Vz0qh0BNon+5ss1JA4xd7seAmXfXieCKJo zPsl7QoUr/glHyWRNXVoHK9pLv/omZmAeXJUhaQUADnQAifFkch6DjjoWqAWVgy6tje1 mCNGBD1jJbNQsyLE/MB+52WW608aux9YIOH7htJarWJE5WwEV+cNiptHX6QA/M6E6eRy JbnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=VyuytHmYOae+USwA1IdG+NGC5LfZPVWqslDgM4A+QUk=; b=OFRE61ISJ9nfs8PA+ADhIi8BYT4cvipR/icFQsT2HJ5PUwOQmWsgL6FjH/Z4py+4Ex LXOEaWwa5mkBhhwIy+ap89tjV5RcWW/6YIyu1kbHkT4/+J7ITbblhJY4xUVy8Nmk8XAX IY1vg01gAHJeHIBQThB50qbF6eMRZfdSVj8t59TsLaBVBWIoNeE2O1kBw5mkYqIqtSxD F7nCuK7LGz7Z8ivy7HEXtrIbSUJh3E5lCPpbsz/GkhJqjrl6HlrJckhPjFXtdnFYN/iH lqC8ZpwmWRdDLbfKSby8mDwHJFHzMajOvkzKRAU3TyqSQieZ6yqjoYnJXapoWfeRVGdr cgLw== X-Gm-Message-State: ANoB5pkW5Z2W0tDsKt/vETae1g4/QmER4l2ZDBzp9xHhgIODeYSRmKCw bXPvT5701XUKW5OfciBzooI5/A== X-Google-Smtp-Source: AA0mqf5hv3jJnLHo1BAcLYjiEAy2dybsOVTiYu+6/RRs4lLc1z1hES243s+MGmzr2OvVK2PbCnLRXQ== X-Received: by 2002:a17:90b:784:b0:218:fa11:5f87 with SMTP id l4-20020a17090b078400b00218fa115f87mr23629525pjz.25.1669655806963; Mon, 28 Nov 2022 09:16:46 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id a24-20020a63d218000000b00477f5ae26bbsm4291828pgg.50.2022.11.28.09.16.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 09:16:46 -0800 (PST) Date: Mon, 28 Nov 2022 09:16:43 -0800 From: Stephen Hemminger To: ikuzar RABE Cc: users@dpdk.org Subject: Re: multi-process support: how to share THE SAME packet between two different processes Message-ID: <20221128091643.2c9284b2@hermes.local> In-Reply-To: References: <20221125090948.07295854@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Mon, 28 Nov 2022 15:10:39 +0100 ikuzar RABE wrote: > In this case: 9. DPDK packet capture libraries and tools =E2=80=94 Data = Plane > Development Kit 22.11.0 documentation > , which > process is responsible of deallocing the memory occupied by a packet ? the > primary process or the dpdk-dumpcap tool process ? > if one process deallocates a memory, the second one will point to nothing= ... >=20 > ikuzar >=20 > i >=20 > Le ven. 25 nov. 2022 =C3=A0 18:09, Stephen Hemminger > a =C3=A9crit : >=20 > > On Fri, 25 Nov 2022 17:27:46 +0100 > > ikuzar RABE wrote: > > =20 > > > Hi all, > > > > > > I would like to know how do you usually proceed to retrieve and share= the > > > same packet read from NIC port between two different processes ? I tr= y to > > > work in zero-copy way. > > > > > > The first process job consists in parsing the packet and make some =20 > > protocol =20 > > > statistics. The second one dumps the same packet into pcap file for = =20 > > further =20 > > > analysis with wireshark for example. > > > > > > I think none of the cases exposed here corresponds to my need: 43. > > > Multi-process Support =E2=80=94 Data Plane Development Kit 22.11.0-rc4 > > > documentation (dpdk.org) > > > < =20 > > https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#:~:text= =3DStandalone%20DPDK%20processes%20are%20primary,process%20with%20same%20DP= DK%20version =20 > > .>. > > > Am I wrong ? > > > > > > is there a dpdk-compliant way to do it with threads instead of proces= ses =20 > > ? =20 > > > > > > Thank you for your help. > > > > > > Regards, > > > > > > ikuzar =20 > > > > Use a ring buffer. > > Why are you reinventing what the pdump library does? > > =20 Please do not top quote on mailing lists. The DPDK uses the concept of packet ownership (like BSD and Linux kernels). The mbuf is allocated by the receiving poll mode driver and returned by the= rx_burst call. At that point ownership is in the application. The application may: - free the mbuf immediately - pass it to a driver transmit; this passes ownership to the PMD - enqueue it in a ring or other mechanism; this passes ownership to the = ring reader The owner, which is a thread in primary or secondary can free the mbuf. It gets a little more complicated if reference counts are used. In that cas= e: - when reference count is decremented to zero, the mbuf is freed - if reference count is greater than one, then the mbuf should be treate= d as read-only. Most code gets the last thing wrong.