From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH] net: introduce big and little endian types
Date: Thu, 08 Dec 2016 17:06:39 +0100
Message-ID: <1568168.EhulpLP1hk@xps13>
References: <a55f9700134c2b5e83b4806df573aefa0c4bab03.1478703591.git.nelio.laranjeiro@6wind.com>
 <20161208093005.GD21794@autoinstall.dev.6wind.com>
 <2772CCE2-A35D-449E-922F-6EEC1F03342C@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org,
 =?ISO-8859-1?Q?N=E9lio?= Laranjeiro <nelio.laranjeiro@6wind.com>, "Ananyev,
 Konstantin" <konstantin.ananyev@intel.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>,
 Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>,
 Neil Horman <nhorman@tuxdriver.com>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
 Olivier Matz <olivier.matz@6wind.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wj0-f173.google.com (mail-wj0-f173.google.com
 [209.85.210.173]) by dpdk.org (Postfix) with ESMTP id CB829106A
 for <dev@dpdk.org>; Thu,  8 Dec 2016 17:06:41 +0100 (CET)
Received: by mail-wj0-f173.google.com with SMTP id tk12so97138196wjb.3
 for <dev@dpdk.org>; Thu, 08 Dec 2016 08:06:41 -0800 (PST)
In-Reply-To: <2772CCE2-A35D-449E-922F-6EEC1F03342C@intel.com>
List-Id: DPDK patches and discussions <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-12-08 13:59, Wiles, Keith:
>=20
> > On Dec 8, 2016, at 3:30 AM, N=E9lio Laranjeiro <nelio.laranjeiro@6w=
ind.com> wrote:
> >=20
> > Hi all,
> >=20
> > Following previous discussions, I would like to gather requirements=
 for
> > v2, currently we have:
> >=20
> > 1. Introduction of new typedefs.
> > 2. Modification of network headers.
> > 3. Modification of rte_*_to_*() functions.
> >=20
> > Point 1. seems not to be an issue, everyone seems to agree on the f=
act
> > having those types could help to document some parts of the code.
>=20
> I never stated these new types were useful in any way, I still believ=
e documentation of the code is the better solution then forcing yet ano=
ther restriction in submitting patches.=20

It would not be a restriction, just a help for those wanting to documen=
t
some tricky parts by using these types.

I see 2 usages:

- in a struct:

rte_be32_t speed; /**< 0 for speed negotiation */
instead of
uint32_t speed; /**< [big endian] 0 for speed negotiation */

- in a function:

rte_be32_t decode_speed (void *);
[...]
speed =3D rte_be_to_cpu_32(decode_speed());

It is difficult to reject something which could help a bit.
Do you really think it would bring some confusion to have some code
using these endianed-types?