From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 898901B12A for ; Fri, 12 Oct 2018 09:24:35 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3F30307D97F; Fri, 12 Oct 2018 07:24:34 +0000 (UTC) Received: from localhost (ovpn-116-163.ams2.redhat.com [10.36.116.163]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E69428DE9; Fri, 12 Oct 2018 07:24:31 +0000 (UTC) Date: Fri, 12 Oct 2018 09:24:29 +0200 From: Jens Freimann To: Maxime Coquelin Cc: dev@dpdk.org, tiwei.bie@intel.com, Gavin.Hu@arm.com Message-ID: <20181012072429.frizbuqdzn5u6byv@jenstp.localdomain> References: <20181003131118.21491-1-jfreimann@redhat.com> <20181003131118.21491-6-jfreimann@redhat.com> <8772e063-9d04-be01-51a4-567665908505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8772e063-9d04-be01-51a4-567665908505@redhat.com> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Fri, 12 Oct 2018 07:24:34 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v7 5/8] net/virtio: implement transmit path for packed queues 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, 12 Oct 2018 07:24:35 -0000 On Thu, Oct 11, 2018 at 07:31:57PM +0200, Maxime Coquelin wrote: > >I'm testing your series, and it gets stuck after 256 packets in transmit >path. When it happens, descs flags indicate it has been made available >by the driver (desc->flags = 0x80), but it is not consistent with the >expected wrap counter value (0). > >Not sure this is the root cause, but it seems below code is broken: > >On 10/03/2018 03:11 PM, Jens Freimann wrote: [snip] >+ >>+ do { >>+ if (idx >= vq->vq_nentries) { >>+ idx = 0; >>+ vq->vq_ring.avail_wrap_counter ^= 1; >>+ } >>+ start_dp[idx].addr = VIRTIO_MBUF_DATA_DMA_ADDR(cookie, vq); >>+ start_dp[idx].len = cookie->data_len; >>+ start_dp[idx].flags = cookie->next ? VRING_DESC_F_NEXT : 0; >>+ start_dp[idx].flags |= >>+ VRING_DESC_F_AVAIL(vq->vq_ring.avail_wrap_counter) | >>+ VRING_DESC_F_USED(!vq->vq_ring.avail_wrap_counter); >>+ if (use_indirect) { >>+ if (++idx >= (seg_num + 1)) >>+ break; >>+ } else { >>+ dxp = &vq->vq_descx[idx]; >>+ idx = dxp->next; >>+ } > >Imagine current idx is 255, dxp->next will give idx 0, right? No it will be VQ_RING_DESC_CHAIN_END which is defined as 32768. >In that case, for desc[0], on next iteration, the flags won't be set >available properly, as vq->vq_ring.avail_wrap_counter isn't updated. It will wrap because VQ_RING_DESC_CHAIN_END is > ring size. I can't reproduce what you see. Do you test with txonly fwd mode? regards, Jens