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 9F715A00C2; Tue, 8 Nov 2022 19:16:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4167C400D7; Tue, 8 Nov 2022 19:16:26 +0100 (CET) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id E0A04400D4 for ; Tue, 8 Nov 2022 19:16:24 +0100 (CET) Received: by mail-pl1-f182.google.com with SMTP id j12so14889514plj.5 for ; Tue, 08 Nov 2022 10:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; 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=6AqOTwYMVGZM3SP0wivZsWXs3HC6OCWLAjzp+OUZYRs=; b=f1h3HHH9Ul1lyyMTEKJLvVdbGLojUHU76JYghEhdk9XWubEU6cplOcXRc4fhhIkWHY NK1YMVbVmUFIINHiWzsIB/vhFPxeGDWS1fiXw/ARVCoD3c1BqWYdkNlJBb9DraHAt/am ajROcIu1yXO8ZD8CXtgS3jjfIiHsMZ+AhLuC7DnsMfI2Ds9k40Y+YlGb/K4lzU9xZEjM Yb3ZDwLM54BctIYNFQDTtPR2Y3iXslLI15nJuAIQ6AxZBR55960V+n/POHnb4dh54OZV kdwKs1TlW5fB3PbZIrkG83S2wFroekieSdwF/oCR6bFo8KgkTZ142fOxF9eKlTxcZ2G2 c26w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=6AqOTwYMVGZM3SP0wivZsWXs3HC6OCWLAjzp+OUZYRs=; b=q2PbX0Xbf/J745TP62VJB+PoHmUO+KK9IeH/1lpiwCdyxvBYbNxsoDPtzX1lSfiLgU CSokzvAU2zJd4GcQkuEMUx62sxsJcZo2WgCip8ldt4XhXRgplI/EBdS1drkjuTj2XSz5 9MSUQq9lC8m9OQn8HCkNqNL7ibx1+NYv+CUMgkElsYAtWDr2kDvv2Xt8pVR7KiALMAvG Jh0i1wJHRi9Lu+kQvyrQNsvWPf7lEs3l8+HnM2/D9ks7TQ34aBr1LQM9BBBvLn4smOWA DC3dmqMLYw0DwupUCaG82+YN/NfKmex59Q0EMWQn2LXIIFRgEUmpSIHQ7/XRZGT98Y3D 3s2Q== X-Gm-Message-State: ACrzQf22C8J8V36r5EdqScVtXn+E+wTMBvRF/zZ7R46GtAl00nhok3Sq 5f+QzVXaQXqiDz4xJyEVWUOsZ35q0IrSVw== X-Google-Smtp-Source: AMsMyM7Um0Wiu9tVD4vhCVl6zaIE+Lh42rTUJD4yiHuTxRL0HlEX+0SA+iNdJfKqgSJAxdLaIhD/rQ== X-Received: by 2002:a17:90b:254e:b0:20b:7e26:f0a0 with SMTP id nw14-20020a17090b254e00b0020b7e26f0a0mr73964305pjb.203.1667931383867; Tue, 08 Nov 2022 10:16:23 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id f20-20020aa79694000000b0056c2e497b02sm6906136pfk.173.2022.11.08.10.16.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Nov 2022 10:16:23 -0800 (PST) Date: Tue, 8 Nov 2022 10:16:20 -0800 From: Stephen Hemminger To: Andrew Rybchenko Cc: dev@dpdk.org Subject: Re: [RFC 2/2] testpmd: cleanup cleanly from signal Message-ID: <20221108101620.0876c41b@hermes.local> In-Reply-To: References: <20221014172328.185219-1-stephen@networkplumber.org> <20221014172328.185219-2-stephen@networkplumber.org> 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 On Sun, 6 Nov 2022 13:50:36 +0300 Andrew Rybchenko wrote: > On 10/14/22 20:23, Stephen Hemminger wrote: > > The original behavior of testpmd was to kill itself when > > it received a SIGINT or SIGTERM. This makes it hard to use > > testpmd in test automation where forwarding loop is started > > and then stopped via SIGTERM. > > Can automatic stop it using SIGINT? Doesn't matter the testpmd code has same bug in SIGINT and SIGTERM. The fundamental problem is that regular signals in Unix model are delivered to the process and any thread may receive them. In the case of testpmd, the signal may arrive inside some driver which is doing some operations with hardware and even holding a lock. Then signal_handler() is called. This code does operations that may interact with driver and other parts of the system. It is a broken way to handle this. There are two ways to handle this problem. One way would be to block the signals and use signalfd() and epoll() to handle them. This would be more difficult and invasive in the testpmd logic. The simpler way is to just set a flag and do the cleanup in the main loop when the flag is detected.