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 B42A443886; Wed, 10 Jan 2024 21:11:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 35236402EC; Wed, 10 Jan 2024 21:11:15 +0100 (CET) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id D8E55402EB for ; Wed, 10 Jan 2024 21:11:13 +0100 (CET) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4T9Jll4c9mz6D90H; Thu, 11 Jan 2024 04:08:51 +0800 (CST) Received: from frapeml100007.china.huawei.com (unknown [7.182.85.133]) by mail.maildlp.com (Postfix) with ESMTPS id 49D801400DD; Thu, 11 Jan 2024 04:11:12 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100007.china.huawei.com (7.182.85.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 10 Jan 2024 21:11:11 +0100 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.035; Wed, 10 Jan 2024 21:11:11 +0100 From: Konstantin Ananyev To: Stephen Hemminger 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 Thread-Topic: Issues around packet capture when secondary process is doing rx/tx Thread-Index: AQHaQdZbww5LrB7u+kG/lMknfiGZILDP/kIwgAIOV4CAAXD9wA== Date: Wed, 10 Jan 2024 20:11:11 +0000 Message-ID: <59dfbb6360104c348b4eb3dc767b0233@huawei.com> References: <20240107175900.1276c0a5@hermes.local> <5c28d2a26f5142c3a509cc8bda2fca75@huawei.com> <20240109150611.00d13e13@hermes.local> In-Reply-To: <20240109150611.00d13e13@hermes.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.168.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > -----Original Message----- > From: Stephen Hemminger > Sent: Tuesday, January 9, 2024 11:07 PM > 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 >=20 > On Mon, 8 Jan 2024 15:13:25 +0000 > Konstantin Ananyev wrote: >=20 > > > I have been looking at a problem reported by Sandesh > > > where packet capture does not work if rx/tx burst is done in secondar= y process. > > > > > > The root cause is that existing rx/tx callback model just doesn't wor= k > > > 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 registe= r callback > > > 2. secondary process calls rx_burst. > > > 3. rx_burst sees the callback but it has pointer pdump_rx which is n= ot 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 multipl= e processes. > > Right now RX/TX callbacks are private for the process, different proces= s 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 c= allbacks. > > > > About pdump itself, it was a while when I looked at it last time, but a= s I remember to start it to work, > > server process has to call rte_pdump_init() which in terns register PDU= MP_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. > > >=20 > Did some more tests with modified testpmd, and reached some conclusions: >=20 > 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. >=20 > 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: >=20 > Primary EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > Secondary: EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_6057_1= ccd4157fd5 >=20 > 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 >=20 > Looks like the whole MP socket mechanism is just not up to this. >=20 > Maybe pdump needs to have its own socket and control thread? > Or MP socket needs to have some multicast fanout to all secondaries? Might be we can do something simpler: pass to pdump_enable(), where we want= to enable it: on primary (remote_ process or secondary (local) process? And then for primary send a message over MP socket (as we doing now), and f= or secondary (itself) just do actual pdump enablement on it's own (install callbacks, etc.). Yes, in that way, one secondary would not be able to enable/idable pdump on= another secondary, only on itself, but might be it is not needed? Konstrantin =20