From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 18125A04B5;
	Mon,  2 Dec 2019 10:30:15 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 56CE11BF73;
	Mon,  2 Dec 2019 10:30:14 +0100 (CET)
Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com
 [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id C85E71F28
 for <dev@dpdk.org>; Mon,  2 Dec 2019 10:30:13 +0100 (CET)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailnew.nyi.internal (Postfix) with ESMTP id 4624A77A6;
 Mon,  2 Dec 2019 04:30:13 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Mon, 02 Dec 2019 04:30:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=mesmtp;
 bh=PPDacV+FpWKivFMRqmqJvSEH6yxgOH/GOr13EI05VYM=; b=Qyk5C2CxobYo
 gaSgp9Q2XzTwV4A0p3I2okqVfVQoZC9RRQtrRcLdtBXdUbOpxVIodXP90FeYWQv/
 QortX4kaNljqvgPHboj12+JmlGLUK3vTJA1S9frxPJLe+kgOZ2hvVu8dmWr0WHE4
 yMtGJicoDR70JgfthIQ1i6KRA5dDn3A=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; bh=PPDacV+FpWKivFMRqmqJvSEH6yxgOH/GOr13EI05V
 YM=; b=xA3VNW51ijCHvYoHvLwWJXdkCpRezJ7UGXVooieeY6nZ5FxKINNcU1nFA
 cJCB6uyUZmrWeYfSWgN0BVNThDyohC42Tfr2ROJI9RdIm+2fvE5/6zxtU9Y6ZWe9
 4ftoxXBgL8uKrdZrkSVsn53WSOVo+TcM9eEGbvFY4q5uXTSyZHM1+1jQAnYnALsi
 GEu//m/n3VViWIvlba2OfXUW3L70KRrRwKoCaqtYMU2pq8FOP0YUMzp+RetNN+II
 TXYVkSClcWaC30FstLLbGIqDM4yJUwE96BR7zEiIYqtU4MJwu4ehp3d4diPetRwT
 8BCSBjFoHpftb7sGYUl3sEmMSiZsw==
X-ME-Sender: <xms:pNnkXXIt5fJQ3b6KkrF4-mo5hncVAr9syFoV_TtOX3wzhaWSw1s44w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejhedgtdeiucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf
 hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh
 ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:pNnkXaJEiOlzk44qAJwtHceqsDyEVO30zn7i0EbmzxRerrHY81-sWw>
 <xmx:pNnkXf2kYke-fkVLZi6mNRm7xRD2pIh6MmWDvvpkUvDdyyWs6X_F4g>
 <xmx:pNnkXSx1BvMhhOcah3init-OTAeBdWJSqtraTopcyH9XHGPvKri23Q>
 <xmx:pdnkXfifSdAQyNPDSF4ShM0wmIrFl_94DRFtSMW4QeEFVgACnh8N6g>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 795E98005C;
 Mon,  2 Dec 2019 04:30:10 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
 "Joyce Kong (Arm Technology China)" <Joyce.Kong@arm.com>, dev@dpdk.org,
 jerinj@marvell.com, stephen@networkplumber.org,
 Bruce Richardson <bruce.richardson@intel.com>, nd <nd@arm.com>,
 david.marchand@redhat.com, Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
 ravi1.kumar@amd.com, rmody@marvell.com, shshaikh@marvell.com,
 xuanziyang2@huawei.com, cloud.wangxiaoyun@huawei.com, zhouguoyang@huawei.com
Date: Mon, 02 Dec 2019 10:30:09 +0100
Message-ID: <2754775.WDKU3ik09V@xps>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60C3D@smartserver.smartshare.dk>
References: <1571125801-45773-1-git-send-email-joyce.kong@arm.com>
 <3338244.xi9Rne9xir@xps>
 <98CBD80474FA8B44BF855DF32C47DC35C60C3D@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [dpdk-dev] [PATCH v5 3/6] net/axgbe: use common rte
	bitoperation APIs instead
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

02/12/2019 10:24, Morten Br=F8rup:
> Thomas,
>=20
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Monday, December 2, 2019 10:12 AM
> >=20
> > 02/12/2019 07:09, Gavin Hu (Arm Technology China):
> > > Hi Bruce, Thomas,
> > >
> > > This series of patches was reported a compilation issue[1] on 32bit
> > Ubuntu.
> > > On mainstream 64-bit OS,  "unsigned long" is 64-bit in size and we
> > uses the 64-bit variant of APIs. But the 32-bit OS expect 32-bit
> > 'unsigned long' arguments.
> > > This is where the error happens.
> >=20
> > Please could you be more specific? What is the exact error?
>=20
> The PMD has a private structure with an unsigned long field.
>=20
> The patch for the PMD uses the 64 bit operations on this field. The patch=
 fails to compile for a 32 bit target, because the struct field is only 32 =
bit there.
>=20
> >=20
> > > My question is how 32-bit OSes shall we support, put another way, can
> > we ignore this compilation issue?
> > > If we still need to care, how about making 'obsolete' of 'unsigned
> > long' and use 'uint32' instead to be multi-OS friendly?
> >=20
> > Which unsigned long?
> > If it is in the (not merged) bit API, it can still be changed no?
> >=20
>=20
> The patch for the PMD can be changed to use the 64 or 32 bit operations d=
epending on whether it is being compiled for a 64 or 32 bit target.
>=20
> However, the question seems to be if we want to either 1) do something li=
ke that, or 2) drop support for 32 bit targets, or 3) make these target dep=
endent fields obsolete (i.e. ban the use of unsigned long) and require expl=
icit sizes, e.g. uint32_t.

We should support both,
and use the appropriate instruction.

But I wonder why this field has not a fixed size.
It would be probably better to change the field to uint32_t or uint64_t.