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 33DD7425B7 for ; Sat, 16 Sep 2023 23:11:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97D1940291; Sat, 16 Sep 2023 23:11:46 +0200 (CEST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 070824026A for ; Sat, 16 Sep 2023 23:11:45 +0200 (CEST) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-573e67cc6eeso2506655a12.2 for ; Sat, 16 Sep 2023 14:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694898704; x=1695503504; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=PKUsnEeGcPo+e5vZlY3oN/LxPku0MaV4CyQyANw1JA4=; b=XfIdOLzA8goCtyO0NwACXBIGTF07vUfB1HW4tv1NmI0Mc2JQcwiMbevb1mrVIrZ1UY UojUBmaMLTzmjnfvz/732uGDNnM6vt60RfAwqzYIw7gyfJO/ihFuvhW9fm/8lW2zWzXP jQAW2UxyFn0JBvp/M6hwyhexy8MwGgvxR760tXgUKp4OucX/kR9m28Fb3Sl0xtiFXOkV IebHrPaod6x3jSe/ayEXpx0BIgB6qMSJ7XrI6gyXJ7rmJX4YL73kWSuw0KCVMY0f1bjZ Tnl42AFYUO8S7rz4rYY4pD34N2AAL6+n2kLJ5CIvcAU9QWC+XzJ9p1Wmr1KwQydtCsG3 lgyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694898704; x=1695503504; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PKUsnEeGcPo+e5vZlY3oN/LxPku0MaV4CyQyANw1JA4=; b=stMy4batEKBFayb44ccq0nTpMl4hY/IirKpCRNEfWDEv+WqjT/MuEaIRhCaKI4Xbnc xPoM7ZD8ptcnOzkJfIMZ87tQadikaFHjAInwpVdv6Ni1dN9eQUyDgOHSjbJDli/QXord xQAYzfDTE1UbcL33i9Ydmsz29fgSyMwHbUbwHcvvalerWSg81+KAfn88j04wgt96qMG3 C5ruEhKbKzb3gHtMfGgZHaAjAUpOFqiNqBiL/ZAhZYeFEuEmd5uAwkt7yaWKqpFLauvr JgSpNVReWNUtrrVK6BeYTlAn0ifW6IP8V9z9wB5bei4EYL2gwWMho4GjtyIdizEUIQ1G S5uA== X-Gm-Message-State: AOJu0Yytbbnpo396X0jFcUA56Kb7P/3gmEGDkMlnYxH4WunWTCd80pvO JvFSruRZFOUDA7H54OrR19Mrl0nLVgSvSAKSkB7zT81aqDk= X-Google-Smtp-Source: AGHT+IHqGkZFnOLRbPNPdMpTsIZ34Sf9VJPAzTgyzzgyCnV6nAz5eoE2XFIeskFADKT4P7YH/M/TMh5qKj6wvqgIzyM= X-Received: by 2002:a17:90a:6e04:b0:268:1b60:5031 with SMTP id b4-20020a17090a6e0400b002681b605031mr4218594pjk.12.1694898703558; Sat, 16 Sep 2023 14:11:43 -0700 (PDT) MIME-Version: 1.0 From: Isaac Boukris Date: Sun, 17 Sep 2023 00:11:31 +0300 Message-ID: Subject: Concurrent invocations of the dpdk-dumpcap tool To: users@dpdk.org, Stephen Hemminger Content-Type: text/plain; charset="UTF-8" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Hello Stephen, all, Currently the dumpcap tool fails if another instance of it captures on the same interface, and the primary process will log: "pdump_register_rx_callbacks(): rx callback for port=0 queue=0, already exists" However if each instance runs on a different port (-i), then they seem to both work fine and capture packets until you stop the second one, at which point the first one breaks with: Packets captured: 196094 Primary process is no longer active, exiting... EAL: failed to send to (/tmp/dpdk/rte/mp_socket) due to Connection refused EAL: Fail to send request /tmp/dpdk/rte/mp_socket:mp_pdump pdump_prepare_client_request(): client request for pdump enable/disable failed RING: Cannot free ring, not created with rte_ring_create() At the same time, the primary process crashes with (which is likely the cause of the above): #3 #4 0x000000000168437d in bucket_dequeue () #5 0x0000000002269c26 in rte_pktmbuf_copy () #6 0x00000000021a4939 in rte_pcapng_copy () #7 0x000000000209d890 in pdump_copy () #8 0x000000000209e350 in pdump_rx () #9 0x0000000002240bb5 in rte_eth_call_rx_callbacks () #10 0x00000000014b04bf in rte_eth_rx_burst (port_id=0, queue_id=0, rx_pkts=0x7f00c3fb9c80, nb_pkts=128) at /usr/local/include/rte_ethdev.h:5906 I'm testing with the 22.11.3 version code (latest LTS) but there don't seem to be significant changes in master. Given the above I had the hunch the ring names collide in shared memory, so I changed both the ring and the pool names in the dumpcap tool to include the pid, and with that the above scenario works fine as expected, is that a proper fix? btw, looking at related code i wondered why do we require the ring to be MC, while we probably need MP since the app might have several producers, is the dumpcap tool the only consumer? In general the fact that if the tool dies abnormally or crashes, requires restarting the primary process isn't great. While we can try to catch more signals in the tool to avoid it, perhaps we can also consider a -F option which disconnects stalled clients (by sending a "disable" message). Another improvement could be to detect on the primary process that the secondary one died and remove the rxtx_callback so another client could connect. Thanks!