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 2C0B1A0548; Fri, 9 Jul 2021 16:48:48 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0B6FB416AD; Fri, 9 Jul 2021 16:48:48 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mails.dpdk.org (Postfix) with ESMTP id 4B6394014D for ; Fri, 9 Jul 2021 16:48:47 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id l18so7718003iow.4 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=aWrdA4TcPyzHkNV76KYghU2ZXCVpCwXDXa8esU6hsTo=; b=JHOZjmcco9VgGra5rPtc1HQzlT0mi2j69DuPh2wBUEX8iKEK5SrFr3nqJw6epivMKJ pad3x4ep8zsphDea4/PyXv00Tb5HarMTL3VrXn0RLg7Rsfjk8jVqpCiDcWmKPeS0gnYa LDo0VTfdqePk0f2FIq2Q9iBOlPHcPWGDmhZ/M= 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=aWrdA4TcPyzHkNV76KYghU2ZXCVpCwXDXa8esU6hsTo=; b=s3AjkQoYkHqQS8/G/MYzhHSxX5kx0KJaOQ2R57yixedM9QBS3JdTDC1cewG45WAJF+ dfZ6lxoAZ1EwadLC8kVJoSw/HKaUDrJEf4BeeXtbytBaCxYl3Jyb6NEnkZGYxOHHRfs0 K5b3x80HvPgmAjTDfJUcQBC8BrxqGmYXvnxcf4xxjG+Ey8PsiBBSjQZLjkwboV8ubDff BwpTY+NIm/HiIrKL7G8nM4fX7E7zIQ1MKF8xi3TsRXxX8uGBSSBsY6HyeoBfiK7Pczpc hEyVUJqwO8w1GuG7hzV+Crd+YZnS/ZzzRNgvEU5XYAlQvTc3KZm0visSELpG5R5xNdty Zcvg== X-Gm-Message-State: AOAM530hoQHhVbyMOG4Ug5TcpUvprbzUjLDebmaXhOnr7hAdgniPjf8d tXiyYTk4jdSTt9pgOIh4nHaecZXyzST9A6yxbgTEdQ== 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="0000000000006e683e05c6b1dee1" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH] net/bnxt: fix missing barriers in completion handling 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 Sender: "dev" --0000000000006e683e05c6b1dee1 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. --0000000000006e683e05c6b1dee1--