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 00A13A0032 for ; Wed, 16 Nov 2022 23:25:52 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EFFB040E03; Wed, 16 Nov 2022 23:25:52 +0100 (CET) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id 0403240DFB for ; Wed, 16 Nov 2022 23:25:51 +0100 (CET) Received: by mail-pj1-f52.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so3678663pjs.4 for ; Wed, 16 Nov 2022 14:25:51 -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=LixGHWn/1mLa25CzpJZ7EApSWr57CY8FcsMgx9LdgtQ=; b=q0ZSXWAr2karFQ6tuI8Lc8o9Bz8nR2iyPvFVShWp9+lVCOl/ffqylxLYr+zm44h64N LnpNJtoealHYzoKd7zGpTNae2lXl4f5Hs0IMac/ZNPCZlbp1pZiHgzjY8QRA2AgG3o0w Gusnd+ggC5n+3HCs3n8bmxLX9e8EyuOO9973K0E66mmXTt8EGF2jedkwVDlAmwqT8NeW taqho4TMfk/IEFrK9dD+CHH8A2v0dvyF/utGfEZWtD8deURn+1kokA/MfVFIOfNsyqrG y9uwqEmcyreu3V9UTR/ktQRJBBR/Ye0sbvoY9HOeYAoZbfi3EkUI3HSPL4g3BIjJhGbw OtWg== 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=LixGHWn/1mLa25CzpJZ7EApSWr57CY8FcsMgx9LdgtQ=; b=kZs8jiNu+/Y99yINrkw8VWgcVumQlCgcqKjkDLuezeE95FVoX2dGNQnFL8kSwzYU7l 0G2gwymqtuQ7QHxkssRiNsCwC1cLmLtCCgkxtzrpFtM06cnklUrbJ+FiDWdzy9UAzr7T WoJGVKeX8WhsJIhk4CzAlQdJ2h71C9DiFefjdCJwAQV5r/q3SZ5YZHeqfBIL+cL2/4JA PPihTIvJ/heRtn1aHkMuu2NiryaalKQT/IBOmYt5zmQZxfmmh3RDDjv7AM+sq6ECwHOZ /KYAPZJfaS+7+PIbV0G7B/1Ko/4booL2jQjila0wL3hFm2vxvWzBvadtNSGb7F4WSatm d/Pg== X-Gm-Message-State: ANoB5pknu6rI4wXs9yfV1pnmfxgGJ5CFgjBEMy6F6GoIO0W1nEv05+x9 DnN5Rp6aavEf2e9RCKWTVvHkcQ== X-Google-Smtp-Source: AA0mqf4iJntc7oBEnmOZCby5HoJ42RunMZ79juoP6Usd96acyOJ7hoL+GLGAvC1pKY22Z2thPXn9EA== X-Received: by 2002:a17:902:c946:b0:188:9542:52d with SMTP id i6-20020a170902c94600b001889542052dmr10970373pla.143.1668637551038; Wed, 16 Nov 2022 14:25:51 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id 17-20020a17090a035100b002009db534d1sm2123080pjf.24.2022.11.16.14.25.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 14:25:50 -0800 (PST) Date: Wed, 16 Nov 2022 14:25:48 -0800 From: Stephen Hemminger To: Luc Pelletier Cc: Konstantin Ananyev , "grive@u256.net" , "dev@dpdk.org" , "stable@dpdk.org" , hyonkim@cisco.com, johndale@cisco.com Subject: Re: [PATCH] failsafe: fix segfault on hotplug event Message-ID: <20221116142548.554a7a9e@hermes.local> In-Reply-To: References: <20221110163410.12734-1-lucp.at.work@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Wed, 16 Nov 2022 16:51:59 -0500 Luc Pelletier wrote: > Hi Konstantin, > > > It is not recommended way to update rte_eth_fp_ops[] contents directly. > > There are eth_dev_fp_ops_setup()/ eth_dev_fp_ops_reset() that supposed > > to be used for that. > > Good to know. I see another fix that was made in a different PMD that > does exactly the same thing: > > https://github.com/DPDK/dpdk/commit/bcd68b68415172815e55fc67cf3947c0433baf74 > > CC'ing the authors for awareness. > > > About the fix itself - while it might help till some extent, > > I think it will not remove the problem completely. > > There still remain a race-condition between rte_eth_rx_burst() and failsafe_eth_rmv_event_callback(). > > Right now DPDK doesn't support switching PMD fast-ops functions (or updating rxq/txq data) > > on the fly. > > Thanks for the information. This is very helpful. > > Are you saying that the previous code also had that same race > condition? It was only updating the rte_eth_dev structure, but I > assume the problem would have been the same since rte_eth_rx_burst() > in DPDK versions <=20 use the function pointers in rte_eth_dev, not > rte_eth_fp_ops. > > Can you think of a possible solution to this problem? I'm happy to > provide a patch to properly fix the problem. Having your guidance > would be extremely helpful. > > Thanks! Changing burst mode on a running device is not safe because of lack of locking and/or memory barriers. Would have been better to not to do this optimization. Just have one rx_burst/tx_burst function and look at what ever conditions are present there.