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 B9CB84385D; Mon, 8 Jan 2024 02:59:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 455B4402B0; Mon, 8 Jan 2024 02:59:07 +0100 (CET) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by mails.dpdk.org (Postfix) with ESMTP id 7EA5640272 for ; Mon, 8 Jan 2024 02:59:05 +0100 (CET) Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-6daf9d5f111so238189b3a.0 for ; Sun, 07 Jan 2024 17:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1704679144; x=1705283944; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=Yu8O72qjRcLokCLuLJBdiVhcBvqP0l2K7puQnHE4vFk=; b=XlwCP6XktWQaMiHhE+2qA3sL+hmuuNcu6Eg0fUoGjtDyhpamL1lv6W0tkiIhHJSzdB 2GXCkFt0LjWedCls+U7iTNSToSi1hqMJbi1n6K/FhUW6ecIJsqo5XtXDd7W77jNB8x74 +P882Wcv3qA7qMVOk3HSqEMvFKfaYEpGSYCWTanqlPXZn00s39XMfI8wW2u+K+nZZ3tS H2Vd0gfTKwNXvCybY+zqR3vidNp96N8ytic3MXdQv423+noq5O0Wkyd1wmKuP5VqQ11b qGXnDM8grqVGGqPMq7lk0nCRluMqRwsLyFF434ohd04M1Wl1y4LfW0x2a7jGkvhilwfa R1vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704679144; x=1705283944; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Yu8O72qjRcLokCLuLJBdiVhcBvqP0l2K7puQnHE4vFk=; b=QX3+2MgZVxe1jP3SCFXtiExHibi62cJLRf6csiKtpoGXebJRyxuP9UQluZz2saj4qR Jis9QmpPSw8PjLUMIEoChgwbrBeigqPCtmKjduMpwq9+vNpxuqnXpp4jYH9VcX785Bzn f2jUVWyg0UNi9bYVaVMTYnGmX3gdjeUO3cZ1S3GiMrW0TzpbJkCmMgsVNZ9EvrQiFpM2 eoY8q7Yz5S/YpmL4sA88f9bB4jktFBhms7seobNdB291Ue5btUWjBU5u4yBUMcnsZvhC hgFRPIilDXziYQBXtNuUu9iepHzjtzFFcugkIfm0AhXLWl3AkCSr8vBgyy96VmLTbSZQ atSA== X-Gm-Message-State: AOJu0YxrSyjaNIjpavzSI/vdipx+9NRTMUJGQ+51msiWXAPZl9RZcyT+ JwFFTBc1YqoyayeWFPxQTrCDQ+tclZnx/UcgLRnoh87k7+A= X-Google-Smtp-Source: AGHT+IHc+WSy+7DMOrMt1VBHAMDDt55Vk4B3orTqh6nuLrExTRdFTunTGVisXGdVkhEcPm+XJm565A== X-Received: by 2002:aa7:8550:0:b0:6d9:c7bd:287f with SMTP id y16-20020aa78550000000b006d9c7bd287fmr3355378pfn.66.1704679144499; Sun, 07 Jan 2024 17:59:04 -0800 (PST) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id jw6-20020a056a00928600b006d95b565418sm4765227pfb.153.2024.01.07.17.59.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jan 2024 17:59:04 -0800 (PST) Date: Sun, 7 Jan 2024 17:59:00 -0800 From: Stephen Hemminger To: dev@dpdk.org Cc: arshdeep.kaur@intel.com, "Gowda, Sandesh" , Reshma Pattan Subject: Issues around packet capture when secondary process is doing rx/tx Message-ID: <20240107175900.1276c0a5@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 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. Some possible workarounds. 1. Keep callback list per-process: messy, but won't crash. Capture won't work without other changes. In this primary would register callback, but secondaries would not use them in rx/tx burst. 2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have a capture flag. (i.e. don't use indirection). Likely ABI problems. Basically, ignore the rx/tx callback mechanism. This is my preferred solution. 3. Some fix up mechanism (in EAL mp support?) to have each process fixup its callback mechanism. 4. Do something in pdump_init to register the callback in same process context (probably need callbacks to be per-process). Would mean callback is always on independent of capture being enabled. 5. Get rid of indirect function call pointer, and replace it by index into a static table of callback functions. Every process would have same code (in this case pdump_rx) but at different address. Requires all callbacks to be statically defined at build time. The existing rx/tx callback is not safe id rx/tx burst is called from different process than where callback is registered.