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 49AB5A0032; Wed, 16 Nov 2022 23:25:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2508D40F18; Wed, 16 Nov 2022 23:25:54 +0100 (CET) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 0540F40E03 for ; Wed, 16 Nov 2022 23:25:51 +0100 (CET) Received: by mail-pj1-f41.google.com with SMTP id u8-20020a17090a5e4800b002106dcdd4a0so3732884pji.1 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=GWD0QMBt/L/j4wAaNBfyss67iTHIgBSKyGWV4D3eFcOaryaRvQavW+wMAdQ/748F2V 3yxiAOVYN4QBzFzEBq5UQ7tktnrhSHxFSoJ1FS+zaV1o1Upz63Hp2bVcV+IJVWawmyfX 6/7Zg3e97Ad7ZI6s2BntNP4i8AIf8+nho/AvEBWBYHriWp0RER4iHgXk9R04PcHuUoUd RxzhtviJ0/OmE6jyoxC4yZi1omBLjXlKpS1PZF/pdy0CWilGemR+RZOD6CiSeOnTibrA OSbtHgUz+iAJt11kLjXQC3Aw2r5nI43iK/uEKAJ3FCubK8HlElSE3zuDguVsY1EO7Azj dLPw== X-Gm-Message-State: ANoB5pmic3IY5bhhJZaVYOpJp5k7ZNBdnPNgofPcRfM0zNobcdDHe9sE Db0kNGf0VgYCrxLMP4TPhZm07g== 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: 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 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.