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 3E3264387A; Wed, 10 Jan 2024 00:07:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B45914026B; Wed, 10 Jan 2024 00:07:12 +0100 (CET) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id 5A2CB4021E for ; Wed, 10 Jan 2024 00:07:11 +0100 (CET) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1d41bb4da91so17506925ad.0 for ; Tue, 09 Jan 2024 15:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704841630; x=1705446430; 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=FbK12R6AarC5QkTNjtJLtlwc5WsH2bgGgjZa6vJzoso=; b=qXLgSPopYfS/Okkc1CKrOnVG5s+VamrenJ/KkStelWdA0VEyj1yWw3VvTXVJYDaHAk IdFtublobKjBNJgCWzJqg4zMPAxCM2Jb7cqP74tNwzkE10xFGw1GzL8RQ9DqLIp4slde b4T2/4ea47A8nWf/dleXqQjJJGTkXcjirCHiSpvtMzvqWVwsRwuLh7YuF43FLghIUj6A gS1p1vlPV5KpuG4zTD8OBHGtPj7YZsyZCgyJdHlc7s5tvNZG9PtnECxK1J7HVx5Zd3mB /WhXndVx/drurdkLJdH5AMsfeD/+PJxZiLqa1opRGIMsLKtcHsxHuV/010XojxGFqgoG g5fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704841630; x=1705446430; 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=FbK12R6AarC5QkTNjtJLtlwc5WsH2bgGgjZa6vJzoso=; b=XylWsOrvbcar1ZnJ2IrTMS5Fi2anW+yHqcd/Ff3Qnavk8eyZHb/StsTc8WsbpkMHC/ YyAsGIXLrAxVz1dkveHg4kWbj778jjZYREczF/JO1+NJ2H3XSfav+zQ8UGbEEeuGdBMD yb445dSosWZwQntE6nviaNNyyY0v7WnwovMhQR6iMf40IM/nRyGp1rkQQbId1NkmxOLR izkJS6nY9+AfC9sfuSn3Makg7Wu4ezrrzVxt4Oi3+zXdsr3lLDeU/jvPMDkzdka5knkg GuQCi638OY2Aue6FWL/XtDkl9vVraPncQqqE+MKJ2QUuY0ZO2AwR1tqJ8Bv8Ce4chLTw nBLw== X-Gm-Message-State: AOJu0YyLEvzjpBoTemirapwmU9+5LRsZH3ogQh0MMBrdN+bxPAVs3dPA CrA0M8kovhWY2s4f7SiKRLNnZ1gATaNKPg== X-Google-Smtp-Source: AGHT+IGz2ttjQUob1zIagmJR35jsAPwuugoCoqx+AUMZpPUbjwGBCp+2X+5qio7EWMDOm1bXHc/9dw== X-Received: by 2002:a17:902:a716:b0:1d4:e084:571e with SMTP id w22-20020a170902a71600b001d4e084571emr77076plq.129.1704841630104; Tue, 09 Jan 2024 15:07:10 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id b6-20020a170902a9c600b001d5383ae01csm1937271plr.121.2024.01.09.15.07.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 15:07:09 -0800 (PST) Date: Tue, 9 Jan 2024 15:07:07 -0800 From: Stephen Hemminger To: Konstantin Ananyev Cc: "dev@dpdk.org" , "arshdeep.kaur@intel.com" , "Gowda, Sandesh" , Reshma Pattan Subject: Re: Issues around packet capture when secondary process is doing rx/tx Message-ID: <20240109150707.2a9ca9bb@hermes.local> In-Reply-To: <20240109150611.00d13e13@hermes.local> References: <20240107175900.1276c0a5@hermes.local> <5c28d2a26f5142c3a509cc8bda2fca75@huawei.com> <20240109150611.00d13e13@hermes.local> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 9 Jan 2024 15:06:47 -0800 Stephen Hemminger wrote: > On Mon, 8 Jan 2024 15:13:25 +0000 > Konstantin Ananyev wrote: > > > > I have been looking at a problem reported by Sandesh > > > where packet capture does not work if rx/tx burst is done in secondary process. > > > > > > The root cause is that existing rx/tx callback model just doesn't work > > > unless the process doing the rx/tx burst calls is the same one that > > > registered the callbacks. > > > > > > An example sequence would be: > > > 1. dumpcap (or pdump) as secondary tells pdump in primary to register callback > > > 2. secondary process calls rx_burst. > > > 3. rx_burst sees the callback but it has pointer pdump_rx which is not necessarily > > > at same location in primary and secondary process. > > > 4. indirect function call in secondary to bad location likely causes crash. > > > > As I remember, RX/TX callbacks were never intended to work over multiple processes. > > Right now RX/TX callbacks are private for the process, different process simply should not > > see/execute them. > > I.E. it callbacks list is part of 'struct rte_eth_dev' itself, not the rte_eth_dev.data that is shared > > between processes. > > It should be normal, wehn for the same port/queue you will end-up with different list of callbacks > > for different processes. > > So, unless I am missing something, I don't see how we can end-up with 3) and 4) from above: > > From my understanding secondary process will never see/call primary's callbacks. > > > > About pdump itself, it was a while when I looked at it last time, but as I remember to start it to work, > > server process has to call rte_pdump_init() which in terns register PDUMP_MP handler. > > I suppose for the secondary process to act as a 'pdump server' it needs to call rte_pdump_init() itself, > > though I am not sure such option is supported right now. > > > > Did some more tests with modified testpmd, and reached some conclusions: > > The logical interface would be to allow rte_pdump_init() to be called by > the process that would be using rx/tx burst API's. > > This doesn't work as it should because the multi-process socket API > assumes that the it only runs the server in primary. The secondary > can start its own MP thread, but it won't work: > > Primary EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > Secondary: EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_6057_1ccd4157fd5 > > The problem is when client (pdump or dumpcap) tries to run, it uses the mp_socket > in the primary which causes: EAL: Cannot find action: mp_pdump > > Looks like the whole MP socket mechanism is just not up to this. > > Maybe pdump needs to have its own socket and control thread? > Or MP socket needs to have some multicast fanout to all secondaries? > > > > > > > > 2. Fut