From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DBE9F4A63 for ; Tue, 24 Mar 2015 11:11:00 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 24 Mar 2015 03:11:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,457,1422950400"; d="scan'208";a="669726254" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by orsmga001.jf.intel.com with ESMTP; 24 Mar 2015 03:11:00 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Mar 2015 18:10:51 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.36]) by shsmsx102.ccr.corp.intel.com ([169.254.2.198]) with mapi id 14.03.0224.002; Tue, 24 Mar 2015 18:10:51 +0800 From: "Xie, Huawei" To: Linhaifeng , "dev@dpdk.org" Thread-Topic: [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty Thread-Index: AdBjLnlvftTdwbn/R/+zVnDJIPL/qg== Date: Tue, 24 Mar 2015 10:10:50 +0000 Message-ID: References: <1426848383-15764-1-git-send-email-haifeng.lin@huawei.com> <550CD696.8070100@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] lib/librte_pmd_virtio fix can't receive packets after rx_q is empty X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 10:11:01 -0000 On 3/21/2015 10:25 AM, Linhaifeng wrote:=0A= >=0A= > On 2015/3/21 0:54, Xie, Huawei wrote:=0A= >> On 3/20/2015 6:47 PM, linhaifeng wrote:=0A= >>> From: Linhaifeng =0A= >>>=0A= >>> If failed to alloc mbuf ring_size times the rx_q may be empty and can't= =0A= >>> receive any packets forever because nb_used is 0 forever.=0A= >> Agreed. In current implementation, once VQ becomes empty, we have no=0A= >> chance to refill it again.=0A= >> The simple fix is, receive one and then refill one as other PMDs. Need= =0A= > "Receive one and then refill one" also have this problem.If refill also= =0A= > failed the VQ would be empty too.=0A= Correction: refill one and receive one on success of refill=0A= >=0A= >> to consider which is best strategy in terms of performance in future.=0A= >> How did you find this? through code review or real workload?=0A= >>> so we should try to refill when nb_used is 0.After otherone free mbuf= =0A= >>> we can restart to receive packets.=0A= >>>=0A= >>> Signed-off-by: Linhaifeng =0A= >>> ---=0A= >>> lib/librte_pmd_virtio/virtio_rxtx.c | 3 ++-=0A= >>> 1 file changed, 2 insertions(+), 1 deletion(-)=0A= >>>=0A= >>> diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c b/lib/librte_pmd_virti= o/virtio_rxtx.c=0A= >>> index 1d74b34..5c7e0cd 100644=0A= >>> --- a/lib/librte_pmd_virtio/virtio_rxtx.c=0A= >>> +++ b/lib/librte_pmd_virtio/virtio_rxtx.c=0A= >>> @@ -495,7 +495,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **= rx_pkts, uint16_t nb_pkts)=0A= >>> num =3D num - ((rxvq->vq_used_cons_idx + num) % DESC_PER_CACHELINE);= =0A= >>> =0A= >>> if (num =3D=3D 0)=0A= >>> - return 0;=0A= >>> + goto refill;=0A= >>> =0A= >>> num =3D virtqueue_dequeue_burst_rx(rxvq, rcv_pkts, len, num);=0A= >>> PMD_RX_LOG(DEBUG, "used:%d dequeue:%d", nb_used, num);=0A= >>> @@ -536,6 +536,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **= rx_pkts, uint16_t nb_pkts)=0A= >>> =0A= >>> rxvq->packets +=3D nb_rx;=0A= >>> =0A= >>> +refill:=0A= >>> /* Allocate new mbuf for the used descriptor */=0A= >>> error =3D ENOSPC;=0A= >>> while (likely(!virtqueue_full(rxvq))) {=0A= >>=0A= >>=0A= =0A=