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 CCAEDA0C45 for ; Tue, 21 Sep 2021 19:45:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AE23A4115F; Tue, 21 Sep 2021 19:45:29 +0200 (CEST) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 0A3AD4115F for ; Tue, 21 Sep 2021 19:45:29 +0200 (CEST) Received: by mail-pj1-f50.google.com with SMTP id mv7-20020a17090b198700b0019c843e7233so148581pjb.4 for ; Tue, 21 Sep 2021 10:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AEi0mjsg6UL65n7EaW2ZZBgMapXZGOs0qzdrgdRDQuE=; b=NkdJ3Vp10JjRsd8D4YMR5ZCNs0K+Rb/ZjMZ8Fg5As4ARrtbJYtVMqpptQ/PCCZunqX uLaVvcZOx2Eo9Ut1cH0IWWXOJlXpE8wOu7Q6dsZLVvNmtivbzSKZp8abHbY87NYftLt3 5bQPxzcjKVdnKT++FH8Wlx6XZjN2BasFEMikQbHAJh2uS57CG/98wspFqJqDMIKa/nzD eyst61JtyecMQcxd4AFMb91kFoZk+n320XaCH/CK09m6f1CanM/xXnWbhlxWmb4WZwsq 2ykfLxVtrjE20N19uvTtP37wsrDbw3ncGPPiIUKZ2dwixVqb6o6A0ai0Rix4yqf20O0/ remw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AEi0mjsg6UL65n7EaW2ZZBgMapXZGOs0qzdrgdRDQuE=; b=5/rK9lopnSP8J3ZM2a/eQWNPu3OYuzDMM5OIfrpRxbYobUZXuswq9mxYFTZgaWbO6u MLa3FRlZVLsFlEF54XrHPsUtDCzmGQlv95j5lpUHdTzkgflGu3YE2uHnipU1GxfgaQmV i6oxAf4Sa3gZ6RlrAd4PEK1vlAyvJ974wJoRNTnQYF4flrRzQIrubdsvmCsu6A6R8sVh aTrX1L9LnJQxHHdyWk4OcTJMcavdEMvht+u991ue5ye4+5kdiCbT1dFx6evlB8xU/oC+ w4rd4wIwXtaLyIVn6bOXU4xT0s+6I8wWS9rbKz1aJSxJW70M4cWMncKtTE5f7/yvF31z zzwQ== X-Gm-Message-State: AOAM530nzafJvoQ5SBf7nnQs3JkxgO52hK18i2sCssUY9XOkX+KtPYkY zDppxpnBdAQBU/A+YzSycRKGYw== X-Google-Smtp-Source: ABdhPJzurKrcoFIgWej+VQdrWH70kIGIzLLddwox9vMfUa6DChK9NKBcc3h74dmYPwaDICbJOth7kA== X-Received: by 2002:a17:903:189:b0:13d:965f:e83f with SMTP id z9-20020a170903018900b0013d965fe83fmr19283579plg.32.1632246328047; Tue, 21 Sep 2021 10:45:28 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id a10sm17766477pfn.48.2021.09.21.10.45.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 10:45:27 -0700 (PDT) Date: Tue, 21 Sep 2021 10:45:24 -0700 From: Stephen Hemminger To: "Loftus, Ciara" Cc: "dev@dpdk.org" , "stable@dpdk.org" , "Yigit, Ferruh" , "Zhang, Qi Z" , "Burakov, Anatoly" Message-ID: <20210921104524.6cda31b9@hermes.local> In-Reply-To: References: <20210903161525.9929-1-stephen@networkplumber.org> <20210920074337.595f3742@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/af_xdp: fix support of secondary process 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 Sender: "stable" On Mon, 20 Sep 2021 15:09:36 +0000 "Loftus, Ciara" wrote: > > > > On Mon, 20 Sep 2021 13:23:57 +0000 > > "Loftus, Ciara" wrote: > > > > > > -----Original Message----- > > > > From: dev On Behalf Of Stephen Hemminger > > > > Sent: Friday 3 September 2021 17:15 > > > > To: dev@dpdk.org > > > > Cc: Stephen Hemminger ; > > > > stable@dpdk.org; xiaolong.ye@intel.com > > > > Subject: [dpdk-dev] [PATCH] net/af_xdp: fix support of secondary > > process > > > > > > > > Doing basic operations like info_get or get_stats was broken > > > > in af_xdp PMD. The info_get would crash because dev->device > > > > was NULL in secondary process. Fix this by doing same initialization > > > > as af_packet and tap devices. > > > > > > > > The get_stats would crash because the XDP socket is not open in > > > > primary process. As a workaround don't query kernel for dropped > > > > packets when called from secondary process. > > > > > > > > Note: this does not address the other bug which is that transmitting > > > > in secondary process is broken because the send() in tx_kick > > > > will fail because XDP socket fd is not valid in secondary process. > > > > > > Hi Stephen, > > > > > > Apologies for the delayed reply, I was on vacation. > > > > > > In the Bugzilla report you suggest we: > > > "mark AF_XDP as broken in with primary/secondary > > > and return an error in probe in secondary process". > > > I agree with this suggestion. However with this patch we still permit > > secondary, and just make sure it doesn't crash for get_stats. Did you change > > your mind? > > > Personally, I would prefer to have primary/secondary either working 100% > > or else not allowed at all by throwing an error during probe. What do you > > think? Do you have a reason/use case to permit secondary processes despite > > some features not being available eg. full stats, tx? > > > > > > Thanks, > > > Ciara > > > > There are two cases where secondary is useful even if send/receive can't > > work from secondary process. > > The pdump and proc-info applications can work with these patches. > > > > I am using XDP over pdump as an easy way to get packets into the code for > > testing. > > > > The flag in the documentation doesn't have a "limited" version. > > If you want, will send another patch to disable secondary support. > > Thanks for explaining. Since there are use cases for secondary, even if the functionality is limited, I don't think it should be disabled. > Since we can't flag it as 'limited' in the feature matrix, could you please add a note about the send/receive limitation in the AF_XDP PMD documentation in a v2? There are already a number of limitations listed, which you can add to. > > Thanks, > Ciara > > > > > Supporting secondary, means adding a mechanism to pass the socket > > around. Looking at this in more detail, and my recommendation is: For 21.11 release (and mark it as Fixes so it gets backported). Have the driver return -ENOTSUP in secondary process. For 22.03 add real secondary support using the rte_mp_msg to pass necessary state to secondary process. Includes socket (and other memory regions?). The pdump and proc-info cases are only useful for developer testing, and there are other ways to do the same thing.