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 1323C41DA8 for ; Sat, 4 Mar 2023 01:07:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8FE4F40E25; Sat, 4 Mar 2023 01:07:37 +0100 (CET) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by mails.dpdk.org (Postfix) with ESMTP id 53759400D7 for ; Sat, 4 Mar 2023 01:07:36 +0100 (CET) Received: by mail-pg1-f171.google.com with SMTP id d10so2445511pgt.12 for ; Fri, 03 Mar 2023 16:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1677888455; 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=lM+16ve0MoEoRtKpg1hD9GWWRIqf2lnoiq8eQkWEeJo=; b=mKTTed+XlHps6RSrhs7myDL9pTeC2dV8CYsLBM8fFOckF3H3pLhNxqs4UZ4+sypfId tSCsSYkaZ1KB6PXcY4748mvv3yagNkyKq2aPXb0qs6tMw9DDRIwDzYzkprM1WcMAUdJx /9UurUe1CmjZhmFbX/CmYwr7oqITZ4OObktY7q3vS3C2di0R7tTS+id05GzwAFSkQe46 gDK1LiMZWMqFZdcs/0UP0Ul6sY8thTs9lt5QJq70YFiuJ74rE1aPxxYJH3mnqeYjbG0i qpzgLcWLerLAlZz+rppAXmCyRxsiCvoHBE80XstkmY+zef6kAdzKl4HZ7Gq+TAnaLMtC jj3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677888455; 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=lM+16ve0MoEoRtKpg1hD9GWWRIqf2lnoiq8eQkWEeJo=; b=VV8LkVSDfXcpaLu8eYFpgladL1sWm8761vsEuA04fvlVtiDvEtuD3ugo4QdFsA6WUe gJXodMOb2j2cBpOULdYK+XXlLnZlcBpxQsRCQyca8LDwBYatImg7rFtw3G6UOx3pCi9k YZmSrMiDhPJFlABSeXVBji3BOTsOxYsv7BA505YnR5WeK7+KnxfpQtVZnxxF68lICyMF shYvS/H6cGwPytncLJ6w2wIioA+fDgV5MDUZttqUUumLgcdkwkZhKD+/xAjyIJt+v1kO oYN8WtVO7imruERjEqZQKi+DcAUpz2ZTvsAn7Erbt6pfAvDumeTfcIE80ZzAB6jqYCMX rjvg== X-Gm-Message-State: AO0yUKXOFAvShnLyYccwlfei1zcsf/QgxmJzHek7Mfx9REbivTza3dL/ 8nzfM9wQHFXHGlpdnhsv6eJhsXMcIeJyKD/ImKUMUA== X-Google-Smtp-Source: AK7set8NH3mDexgTUfRxUzErpBfQAdj5TvX9TDFb0ir1PmOaeisxjvexLiWbgy2mISiwUMqPURs69w== X-Received: by 2002:a62:1c58:0:b0:5e3:16fc:b58e with SMTP id c85-20020a621c58000000b005e316fcb58emr3335693pfc.21.1677888455201; Fri, 03 Mar 2023 16:07:35 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id 17-20020aa79151000000b005cc52ea452csm2151476pfi.100.2023.03.03.16.07.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Mar 2023 16:07:35 -0800 (PST) Date: Fri, 3 Mar 2023 16:07:33 -0800 From: Stephen Hemminger To: Isaac Boukris Cc: users@dpdk.org Subject: Re: Multi-process limitations when using the dumpcap tool Message-ID: <20230303160733.459fa172@hermes.local> In-Reply-To: References: <20230303141823.09bf1563@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Sat, 4 Mar 2023 00:37:53 +0200 Isaac Boukris wrote: > On Sat, Mar 4, 2023 at 12:18 AM Stephen Hemminger > wrote: > > > > On Fri, 3 Mar 2023 12:33:20 +0200 > > Isaac Boukris wrote: > > > > > Hello, > > > > > > The dumpcap documentation points out that it runs as a secondary process, > > > as such I was wondering whether the multi-process limitations such as the > > > requirement to disable ASLR on both processes, and more importantly the > > > limitations regarding the use of librte_hash, also apply when using the > > > dumpcap tool? > > > > > > Thanks! > > > > Dumpcap is passive and have not heard of any problems related to ASLR. > > I realized upon sending that the librte_hash limitation is likely only > when sharing tables between processes, I guess that's what you mean by > passive. > > Thanks! It is more about where data could be allocated. The only allocation in dumpcap or pdump that matters is the associated mbuf pool. This is allocated out of normal hugepage memory which is pinned in both primary/secondary at same address.