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 9ACEB43DFA; Thu, 4 Apr 2024 17:21:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 39CAD4064A; Thu, 4 Apr 2024 17:21:07 +0200 (CEST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by mails.dpdk.org (Postfix) with ESMTP id 84A11402E8 for ; Thu, 4 Apr 2024 17:21:05 +0200 (CEST) Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6e74aa08d15so862069b3a.1 for ; Thu, 04 Apr 2024 08:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712244064; x=1712848864; 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=rkd9hhguIduezRgtra4ibVT2BmPE4fjj4UgSXHiTF6E=; b=QWS43Woy63Up9C8oozhqyxYP6aEqFOZt7WV79gCW4AWxb8rlD1qpuVwINCic82GKXd b3gJr+BYpFXL6XTtzuP4iaSBwaYWER8cRC3KsBZc7nVlP5hD/wP+Fd34VYVAFST0gm69 UKmLKw4ZvXFcbQlNBgX2c8ZDAqJj7ilsMne95j0A5Fvhu/yRrtw15PPT4ibUjq6c5A2X AqziiY0iR1AcontjyvOp1UeumTa6BkZp4FowOoGRFtBbjcmfRlRAnvlGqNfKVGN6CR6W j5a+LgE/MSesYjMogzlslir1m9fSXQ9qs5VVEusVX5NC1a2ubE917zNAvpEvsQsX/sNG xs2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712244064; x=1712848864; 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=rkd9hhguIduezRgtra4ibVT2BmPE4fjj4UgSXHiTF6E=; b=B72tpw+UQqKB4xnvhBTHis/JPcw1T/eGcJKk334EPoCcjSNMXeWz5itU/V45vxUhBz AYBnqVXhurIsn9oVFZZ0woVtL0Kw9VgFlV4ienWX3XvKejQGnPivwRFxr6oxvMp+yG5H NpQ7VSvR2geC9KueWuZcY+j74lQz6lw02mo1mw6zKRVbid+25RiKEt8qPz962aAtgMDe LBGJQTYZMkjQ5AJnl39ceGOPrl/JMAONXH2ggOMMwi13p+9IFndJsudSt5ztuY28rdYg IXCiysdulGddw4lOauEW92SUvUizmkCr/nDPkr4j8/1t1XXa4OZbUVDMrALuDgnKYp3u NtAQ== X-Forwarded-Encrypted: i=1; AJvYcCWcbBVSroKSfk5LGj4Tvl1XX92ZTKNT95oVFRNY5+etggcOiyOollkPsxGRP2d71lCZhKmQe20p2SNBBxY= X-Gm-Message-State: AOJu0YwMOxs1flMObRw/DYINlsPCnaQRqznm5vQpCKbGJrtXB7tQoqMR 3rtWqshz8nfo0g4XutU49oe/DJqY7dLB3v7RPk86HGXGDWbkqC9p+Twwdjtrz7E= X-Google-Smtp-Source: AGHT+IHb59mP0hv3uPgKlwuMq8b/Wl+B6Se/+SY2urgRHl5opkhjbklXZgmhuMitQhuexwyCUTlOBQ== X-Received: by 2002:a05:6a00:2195:b0:6e5:faca:3683 with SMTP id h21-20020a056a00219500b006e5faca3683mr3430120pfi.26.1712244064564; Thu, 04 Apr 2024 08:21:04 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id u6-20020aa78386000000b006e6a16acf85sm13843875pfm.87.2024.04.04.08.21.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Apr 2024 08:21:04 -0700 (PDT) Date: Thu, 4 Apr 2024 08:21:02 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Konstantin Ananyev , "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: <20240404082102.7d9af800@hermes.local> In-Reply-To: <4aee87dd-f4fd-4d74-b2e1-a3b7b195e41c@amd.com> References: <20240107175900.1276c0a5@hermes.local> <5c28d2a26f5142c3a509cc8bda2fca75@huawei.com> <20240109150611.00d13e13@hermes.local> <59dfbb6360104c348b4eb3dc767b0233@huawei.com> <6303f2bf-fc5c-46dd-bcac-f79c0c824a02@amd.com> <04daf6bc50184e9398f0a0ac0bc42759@huawei.com> <4aee87dd-f4fd-4d74-b2e1-a3b7b195e41c@amd.com> 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 > >>>> 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 for 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? > >>> > >>> > >> > >> How secondary, lets say testpmd secondary, install callbacks without > >> getting 'mp' & 'ring' info from pdump secondary process? > > > > Please see my comment above (I copied it here too): > >> Yes, in that way, one secondary would not be able to enable/disable pdump on another secondary, only on itself, but might be it is not needed? > > > > I saw it Konstantin, but it wasn't clear to me what you are suggesting, > that is why I am asking more. > > Do you suggest when testpmd run as secondary process and doing > forwarding, it should do the tasks of pdump itself and we don't use > pdump at all? > I looked into starting pdump_init in the active secondary process, but that won't work right because the passive secondary won't talk to it over the right unix domain socket. It might be possible to have multiple MP server sockets and use some form of AF_UNIX multicast, but it gets complex to handle. Probably best to skip callbacks for this and use a state flag in eth_dev_driver.