From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <huawei.xie@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 3A4D98E56 for <dev@dpdk.org>; Thu, 24 Sep 2015 20:35:46 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 24 Sep 2015 11:35:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,582,1437462000"; d="scan'208";a="796640916" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 24 Sep 2015 11:35:42 -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.248.2; Thu, 24 Sep 2015 11:35:41 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx122.amr.corp.intel.com (10.18.125.37) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 24 Sep 2015 11:35:40 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.75]) by shsmsx102.ccr.corp.intel.com ([169.254.2.179]) with mapi id 14.03.0248.002; Fri, 25 Sep 2015 02:35:38 +0800 From: "Xie, Huawei" <huawei.xie@intel.com> To: Stephen Hemminger <stephen@networkplumber.org> Thread-Topic: [dpdk-dev] [PATCH] virtio: fix used ring address calculation Thread-Index: AdD2muprNE0MPM/rRbSxj2BYBglYmg== Date: Thu, 24 Sep 2015 18:35:37 +0000 Message-ID: <C37D651A908B024F974696C65296B57B40F2E435@SHSMSX101.ccr.corp.intel.com> References: <1442806742-32547-1-git-send-email-huawei.xie@intel.com> <C37D651A908B024F974696C65296B57B40F2CA05@SHSMSX101.ccr.corp.intel.com> <20150924093617.6fd22053@urahara> 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 Cc: "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] [PATCH] virtio: fix used ring address calculation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 24 Sep 2015 18:35:46 -0000 On 9/25/2015 12:36 AM, Stephen Hemminger wrote:=0A= > On Thu, 24 Sep 2015 07:30:41 +0000=0A= > "Xie, Huawei" <huawei.xie@intel.com> wrote:=0A= >=0A= >> On 9/21/2015 11:39 AM, Xie, Huawei wrote:=0A= >> vring_size calculation should consider both used_event_idx at the tail= =0A= >> of avail ring and avail_event_idx at the tail of used ring.=0A= >> Will merge those two fixes and send a new patch.=0A= >>> used event idx is put at the end of available ring. It isn't taken into= account=0A= >>> when we calculate the address of used ring. Fortunately, it doesn't int= roduce=0A= >>> the bug with fixed queue number 256 and 4KB alignment.=0A= >>>=0A= >>> Signed-off-by: hxie5 <huawei.xie@intel.com>=0A= >>> ---=0A= >>> drivers/net/virtio/virtio_ring.h | 2 +-=0A= >>> 1 file changed, 1 insertion(+), 1 deletion(-)=0A= >>>=0A= >>> diff --git a/drivers/net/virtio/virtio_ring.h b/drivers/net/virtio/virt= io_ring.h=0A= >>> index a16c499..92e430d 100644=0A= >>> --- a/drivers/net/virtio/virtio_ring.h=0A= >>> +++ b/drivers/net/virtio/virtio_ring.h=0A= >>> @@ -145,7 +145,7 @@ vring_init(struct vring *vr, unsigned int num, uint= 8_t *p,=0A= >>> vr->avail =3D (struct vring_avail *) (p +=0A= >>> num * sizeof(struct vring_desc));=0A= >>> vr->used =3D (void *)=0A= >>> - RTE_ALIGN_CEIL((uintptr_t)(&vr->avail->ring[num]), align);=0A= >>> + RTE_ALIGN_CEIL((uintptr_t)(&vr->avail->ring[num + 1]), align);=0A= >>> }=0A= >>> =0A= >>> /*=0A= > Why aren't we just using the standard Linux includes for this?=0A= > See <linux/virtio_ring.h> and the function vring_init()=0A= >=0A= > Keeping parallel copies of headers is prone to failures.=0A= Agree.=0A= Using standard Linux includes then at least we don't need to redefine=0A= the feature and other related MACRO.=0A= This applies to vhost as well.=0A= For vring, vring_init, we could also reuse the linux implementation=0A= unless we have strong reason to define our own structure.=0A= One reason was to support both FreeBSD and Linux. FreeBSD should have=0A= its own header file. To avoid the case they have different vring=0A= structure or VIRTIO_F_xx macro name, they are redefined here.=0A= =0A= >=0A= =0A=