From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <andy@warmcat.com>
Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82])
by dpdk.org (Postfix) with ESMTP id 833111BD94
for <dev@dpdk.org>; Mon, 14 May 2018 02:02:46 +0200 (CEST)
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org
References: <152609021699.121661.5295227351721865436.stgit@localhost.localdomain>
<152609040775.121661.12633606299514774674.stgit@localhost.localdomain>
<10112839.slRIOooWqA@xps>
From: Andy Green <andy@warmcat.com>
Message-ID: <a3d0eae5-42f2-b6a2-1273-5013cfc23bd7@warmcat.com>
Date: Mon, 14 May 2018 08:02:27 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.7.0
In-Reply-To: <10112839.slRIOooWqA@xps>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v3 17/24] rte_byteorder.h: explicit cast for
return promotion
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://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: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 00:02:46 -0000
On 05/14/2018 12:59 AM, Thomas Monjalon wrote:
> 12/05/2018 04:00, Andy Green:
>> --- a/lib/librte_eal/common/include/generic/rte_byteorder.h
>> +++ b/lib/librte_eal/common/include/generic/rte_byteorder.h
>> @@ -123,7 +123,7 @@ typedef uint64_t rte_le64_t; /**< 64-bit little-endian value. */
>> static inline uint16_t
>> rte_constant_bswap16(uint16_t x)
>> {
>> - return RTE_STATIC_BSWAP16(x);
>> + return (uint16_t)RTE_STATIC_BSWAP16((uint16_t)x);
>> }
>
> x is already uint16_t, and RTE_STATIC_BSWAP16 is already casting to uint16_t.
> So why these casts are needed?
After winding dpdk back inside lagopus without this patch and recooking
everything...
In file included from
/projects/lagopus/src/dpdk/build/include/rte_byteorder.h:15,
from /projects/lagopus/src/dataplane/dpdk/pktbuf.h:27,
from ./ofproto/mbtree.c:50:
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h: In
function 'rte_constant_bswap16':
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:54:45:
warning: conversion from 'int' to 'uint16_t' {aka 'short unsigned int'}
may change value [-Wconversion]
((((uint16_t)(v) & UINT16_C(0x00ff)) << 8) | \
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
(((uint16_t)(v) & UINT16_C(0xff00)) >> 8))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/projects/lagopus/src/dpdk/build/include/generic/rte_byteorder.h:126:9:
note: in expansion of macro 'RTE_STATIC_BSWAP16'
return RTE_STATIC_BSWAP16(x);
^~~~~~~~~~~~~~~~~~
> And why not in rte_constant_bswap32/64?
It's likely also needed there. I removed the second cast and then
repeated the fix on 32/64 as well.
GCC8 building lagopus blowing chunks is my only insight into these api
header problems in dpdk. It only blew on bswap16.
I simply want to build lagopus with latest pieces to assess how much
risk signing up to use lagopus (and its dependencies) ongoing gets me
into. So my goal is fix all the build issues around that and then why
not provide the patches to the projects since they are done by then.
(My lagopus fixes will have no meaning unless the dpdk fixes get in
first, so I defer interacting with them).
I can get that to build (I think... I have to pin the dpdk subproject,
make clean, make dpdk and then finally make to see the warnings
repeatably) with master dpdk now with my dpdk series of ~45 patches, but
it requires 25 patches on lagopus and there are still a ton of warnings
to clean out and an api change about color / metering I just hacked out
for now. I didn't look too closely yet but maybe some more dpdk header
usage issues to come.
-Andy