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 31A8AA0548 for ; Fri, 9 Jul 2021 16:48:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 246C8416C2; Fri, 9 Jul 2021 16:48:49 +0200 (CEST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by mails.dpdk.org (Postfix) with ESMTP id 50676416AD for ; Fri, 9 Jul 2021 16:48:47 +0200 (CEST) Received: by mail-io1-f54.google.com with SMTP id u7so12678408ion.3 for ; Fri, 09 Jul 2021 07:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jwh8PFg7uatt1vc8r6+N/ff8iqg1H9V0mjrDUEuYcK4=; b=G0e44f2yvyjnqXNRjWTI171Jjc9sBrCzBwYth+PxeEFpvi1D2XM7IwfkijFqbSkBkF D0lZkGsO4Zs+LWJIC4+KVtQl+JSqwiBoVOlwMhWqcR9GldrZghi14oFt0yKYeJpy9u2B P8EzDKN5MbJj/nNVGZcUdOfb5pxsX1Lm9CRX0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jwh8PFg7uatt1vc8r6+N/ff8iqg1H9V0mjrDUEuYcK4=; b=jqtYM+uoYByD4xZLJT48KQnANN2AUKCgL18WcWHAfzyX0op44b+9q9qVRQyqByLe1F 57UtZW4TF1/Ne1GecrxN45WW6usSHiqzhzrMZJbJpiZmezg+Jwzq2Dj+5KhSI1V4+SKZ sulCS/Qdi4pnFb+OoE1wf2hUv86lMbO/aaV3FMqP3clc8VpplOvZE63CcmXkwgqiNCKq j+RkWqVR1BMgUqtwRQRLt6gRrGdNw7fkv8Vz4gBZQOphuDn+MT1F+mj58/CL/hsJ0oa3 ZqXNxIqpd7ovKbK2gqiY+f/GWfCdhOtrvBZVj/T9BtX9Aoh+Jq2pMO/NFbXLKDdv2IAt 6zLg== X-Gm-Message-State: AOAM532tJv5GB4KJLY6fvXOvc945Z45RQ1TuTHTeGZEd8mpryNVXSG0M gzc7ELowEhXD2Tfj5uIBRXSWwpkGWELjVNUCPebXGg== X-Google-Smtp-Source: ABdhPJyqPnIDBEl7EMUkKSjlQeHoJZop5tKgVT562pWqO6NHv1d9rW+B1qpIIcjEWKGdj/7Yy653M/4ffSwxmJ855TY= X-Received: by 2002:a6b:c90f:: with SMTP id z15mr20193482iof.183.1625842126527; Fri, 09 Jul 2021 07:48:46 -0700 (PDT) MIME-Version: 1.0 References: <20210708191501.77972-1-lance.richardson@broadcom.com> In-Reply-To: From: Lance Richardson Date: Fri, 9 Jul 2021 10:48:35 -0400 Message-ID: To: Ruifeng Wang Cc: "Ajit Khaparde (ajit.khaparde@broadcom.com)" , Somnath Kotur , Bruce Richardson , Konstantin Ananyev , "jerinj@marvell.com" , Stephen Hurd , David Christensen , "dev@dpdk.org" , "stable@dpdk.org" , nd Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006e68bc05c6b1dee9" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-stable] [PATCH] net/bnxt: fix missing barriers in completion handling 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" --0000000000006e68bc05c6b1dee9 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 9, 2021 at 2:00 AM Ruifeng Wang wrote: > > > +/** > > + * Check validity of a completion ring entry. If the entry is valid, include a > > + * C11 __ATOMIC_ACQUIRE fence to ensure that subsequent loads of fields > > in the > > + * completion are not hoisted by the compiler or by the CPU to come before > > the > > + * loading of the "valid" field. > > + * > > + * Note: the caller must not access any fields in the specified completion > > + * entry prior to calling this function. > > + * > > + * @param cmp > Nit, cmpl Thanks, good catch. I'll fix this in v2. > > > > > /* Check to see if hw has posted a completion for the descriptor. */ > > @@ -3327,7 +3327,7 @@ bnxt_tx_descriptor_status_op(void *tx_queue, > > uint16_t offset) > > cons = RING_CMPL(ring_mask, raw_cons); > > txcmp = (struct tx_cmpl *)&cp_desc_ring[cons]; > > > > - if (!CMP_VALID(txcmp, raw_cons, cp_ring_struct)) > > + if (!bnxt_cpr_cmp_valid(txcmp, raw_cons, ring_mask + 1)) > cpr->cp_ring_struct->ring_size can be used instead of 'ring_mask + 1'? > > > break; > > > > if (CMP_TYPE(txcmp) == TX_CMPL_TYPE_TX_L2) > > > > > diff --git a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c > > b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c > > index 263e6ec3c..13211060c 100644 > > --- a/drivers/net/bnxt/bnxt_rxtx_vec_neon.c > > +++ b/drivers/net/bnxt/bnxt_rxtx_vec_neon.c > > @@ -339,7 +339,7 @@ bnxt_handle_tx_cp_vec(struct bnxt_tx_queue *txq) > > cons = RING_CMPL(ring_mask, raw_cons); > > txcmp = (struct tx_cmpl *)&cp_desc_ring[cons]; > > > > - if (!CMP_VALID(txcmp, raw_cons, cp_ring_struct)) > > + if (!bnxt_cpr_cmp_valid(txcmp, raw_cons, ring_mask + 1)) > Same here. I think cpr->cp_ring_struct->ring_size can be used and it avoids calculation. > Also some places in other vector files. It's true that cpr->cp_ring_struct->ring_size and ring_mask + 1 are equivalent, but there doesn't seem to be a meaningful difference between the two in the generated code. Based on disassembly of x86 and Arm code for this function, the compiler correctly determines that the value of ring_mask + 1 doesn't change within the loop, so it is only computed once. The only difference would be in whether an add instruction or a load instruction is used to put the value in the register. --0000000000006e68bc05c6b1dee9--