From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 566F537B2; Fri, 14 Apr 2017 09:14:23 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2017 00:14:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,197,1488873600"; d="scan'208";a="87388399" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 14 Apr 2017 00:14:11 -0700 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 14 Apr 2017 00:14:10 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 14 Apr 2017 00:14:10 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.117]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.217]) with mapi id 14.03.0319.002; Fri, 14 Apr 2017 15:14:08 +0800 From: "Tan, Jianfeng" To: Yuanhan Liu CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "stable@dpdk.org" Thread-Topic: [PATCH] net/virtio-user: fix not working on 32-bit system Thread-Index: AQHStF/xk5zTxFQGQEK1/vlMcRjm3qHD0h8AgACJeXD//4PqgIAAjp3A//981ACAAIkWQA== Date: Fri, 14 Apr 2017 07:14:08 +0000 Message-ID: References: <1492092776-57008-1-git-send-email-jianfeng.tan@intel.com> <20170414053222.GK7333@yliu-dev.sh.intel.com> <20170414062017.GM7333@yliu-dev.sh.intel.com> <20170414070114.GN7333@yliu-dev.sh.intel.com> In-Reply-To: <20170414070114.GN7333@yliu-dev.sh.intel.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] net/virtio-user: fix not working on 32-bit system 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, 14 Apr 2017 07:14:25 -0000 > -----Original Message----- > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com] > Sent: Friday, April 14, 2017 3:01 PM > To: Tan, Jianfeng > Cc: dev@dpdk.org; olivier.matz@6wind.com; stable@dpdk.org > Subject: Re: [PATCH] net/virtio-user: fix not working on 32-bit system >=20 > On Fri, Apr 14, 2017 at 06:56:01AM +0000, Tan, Jianfeng wrote: > > > > > > > -----Original Message----- > > > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com] > > > Sent: Friday, April 14, 2017 2:20 PM > > > To: Tan, Jianfeng > > > Cc: dev@dpdk.org; olivier.matz@6wind.com; stable@dpdk.org > > > Subject: Re: [PATCH] net/virtio-user: fix not working on 32-bit syste= m > > > > > > On Fri, Apr 14, 2017 at 05:53:55AM +0000, Tan, Jianfeng wrote: > > > > > > diff --git a/drivers/net/virtio/virtqueue.h > > > b/drivers/net/virtio/virtqueue.h > > > > > > index f9e3736..f43ea70 100644 > > > > > > --- a/drivers/net/virtio/virtqueue.h > > > > > > +++ b/drivers/net/virtio/virtqueue.h > > > > > > @@ -72,7 +72,8 @@ struct rte_mbuf; > > > > > > * Return the physical address (or virtual address in case of > > > > > > * virtio-user) of mbuf data buffer. > > > > > > */ > > > > > > -#define VIRTIO_MBUF_ADDR(mb, vq) (*(uint64_t > *)((uintptr_t)(mb) > > > + > > > > > (vq)->offset)) > > > > > > +#define VIRTIO_MBUF_ADDR(mb, vq) \ > > > > > > + ((uint64_t)((uintptr_t)(*(void **)((uintptr_t)(mb) + (vq)- > >offset)))) > > > > > > > > > > The "void **" cast makes it a bit complex (thus hard to read). I = think > > > > > following should work? > > > > > > > > Yes, uintptr_t can work. I thought void ** is easier to understand, > meaning > > > a convert to a pointer which pointing to a pointer. > > > > > > It's twisted, isn't it? :) > > > > > > > I usually use uintptr_t only for converter from pointer to integer,= not > the > > > opposite way. > > > > > > Yes, that's a typical usage. But the fact of the matter is uintptr_t > > > represents the word size, which is exactly what needed in this case. > > > > Another fold, if you refer to the definition of struct rte_mbuf, the fi= rst field > is defined as void * instead of uintptr_t. I think that why I prefer to u= se ((void > *)*) in the beginning. >=20 > But the type is hidden here: isn't this the purpose you were introducing > the "offset" here? Besides, it could be type "phys_addr_t". >=20 Fair enough.