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 A352D43863; Mon, 8 Jan 2024 11:41:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38A1B40263; Mon, 8 Jan 2024 11:41:23 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id BAE3040261 for ; Mon, 8 Jan 2024 11:41:21 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 7D4B12049C; Mon, 8 Jan 2024 11:41:21 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issues around packet capture when secondary process is doing rx/tx X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 8 Jan 2024 11:41:17 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F119@smartserver.smartshare.dk> In-Reply-To: <20240107175900.1276c0a5@hermes.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues around packet capture when secondary process is doing rx/tx Thread-Index: AdpB1kWeOyge4zDfTWe1mHs9Z+XWzwAR6LLw References: <20240107175900.1276c0a5@hermes.local> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Stephen Hemminger" , Cc: , "Gowda, Sandesh" , "Reshma Pattan" 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 > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Monday, 8 January 2024 02.59 >=20 > 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. >=20 > 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. So, callbacks don't work across processes, because code might differ = across processes. If process A is running, and RX'ing and TX'ing, and process B wants to = install its own callbacks (e.g. packet capture) on RX and RX, we = basically want process A to execute code residing in process B, which is = impossible. An alternative could be to pass the packets through a ring in shared = memory. However, this method would add the ring processing latency of = process B to the RX/TX latency of process A. I think we can conclude that callbacks are one of the things that don't = work with secondary processes. With this decided, we can then consider how to best add packet capture. = The concept of passing "data" (instead of calling functions) across = processes obviously applies to this use case. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 3. Some fix up mechanism (in EAL mp support?) to have each > process fixup > its callback mechanism. >=20 > 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. >=20 > 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. >=20 > The existing rx/tx callback is not safe id rx/tx burst is called from > different process > than where callback is registered. >=20