From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id DFB2B7D0B for ; Fri, 25 Aug 2017 17:41:08 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 25 Aug 2017 08:41:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,426,1498546800"; d="scan'208";a="143912450" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 25 Aug 2017 08:41:07 -0700 Received: from fmsmsx122.amr.corp.intel.com (10.18.125.37) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 25 Aug 2017 08:41:06 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.198]) by fmsmsx122.amr.corp.intel.com ([169.254.5.225]) with mapi id 14.03.0319.002; Fri, 25 Aug 2017 08:41:06 -0700 From: "Wiles, Keith" To: David Harton CC: "skhare@vmware.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] vmxnet3: replenish ring buffers in rx processing Thread-Index: AQHTHbX8ETBKbEdruki/s+2clQo2BaKVqwsA Date: Fri, 25 Aug 2017 15:41:06 +0000 Message-ID: <6EECE57F-E22D-4513-B232-B97548EE4676@intel.com> References: <20170825152211.10911-1-dharton@cisco.com> In-Reply-To: <20170825152211.10911-1-dharton@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.72.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] vmxnet3: replenish ring buffers in rx processing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:41:09 -0000 > On Aug 25, 2017, at 10:22 AM, David Harton wrote: >=20 > vmxnet3 rx processing should replenish ring buffers after new buffers > are available to prevent the interface from getting stuck in a state > that no new work is processed. >=20 > Signed-off-by: David Harton > --- > drivers/net/vmxnet3/vmxnet3_rxtx.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) >=20 > diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmx= net3_rxtx.c > index d9cf437..9861d35 100644 > --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c > +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c > @@ -880,6 +880,23 @@ > } > } >=20 > + if (unlikely(nb_rxd =3D=3D 0)) { > + uint32_t avail; > + for (ring_idx =3D 0; ring_idx < VMXNET3_RX_CMDRING_SIZE; ring_idx++) { > + avail =3D vmxnet3_cmd_ring_desc_avail(&rxq->cmd_ring[ring_idx]); > + if (unlikely(avail > 0)) { > + /* try to alloc new buf and renew descriptors */ > + vmxnet3_post_rx_bufs(rxq, ring_idx); > + } > + } > + if (unlikely(rxq->shared->ctrl.updateRxProd)) { > + for (ring_idx =3D 0; ring_idx < VMXNET3_RX_CMDRING_SIZE; ring_idx++) = { > + VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * V= MXNET3_REG_ALIGN), Did you run checkpatch here as it seems the line length is greater then 80. BTW, I think requirements of 80 and tab length of 8, is a bit outdated in 2= 017 :-( > + rxq->cmd_ring[ring_idx].next2fill); > + } > + } > + } > + > return nb_rx; > } >=20 > --=20 > 1.8.3.1 >=20 Regards, Keith