From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: difficulty w/ RTE_NEXT_ABI
Date: Sat, 21 Nov 2015 11:44:20 +0100
Message-ID: <2295250.tyqBLnBnCL@xps13>
References: <20151121084935.GA24056@mhcomputing.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Matthew Hall <mhall@mhcomputing.net>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
 by dpdk.org (Postfix) with ESMTP id 5930B8D38
 for <dev@dpdk.org>; Sat, 21 Nov 2015 11:45:36 +0100 (CET)
Received: by wmvv187 with SMTP id v187so102960221wmv.1
 for <dev@dpdk.org>; Sat, 21 Nov 2015 02:45:36 -0800 (PST)
In-Reply-To: <20151121084935.GA24056@mhcomputing.net>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2015-11-21 03:49, Matthew Hall:
> I was trying to rebase my DPDK onto v2.1.0 and I came across some very 
> confusing code in examples/l3fwd/main.c .
> 
> So... this code used the RTE_NEXT_ABI macros on a change which does not appear 
> to affect the API... on a function that is marked always_inline ???
> 
> Maybe I missed something but this seems pointless. An always_inline function 
> is going to have to be recompiled in any case.
> 
> Now I have no clue what would makes sense for my version of the function 
> either... because RTE_NEXT_ABI is a binary on/off but trying to track a 
> multi-variate quantity of ABI updates.
> 
> For now I guess I have to write it like this inside the RTE_NEXT_ABI:
> 
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t ptype)
> 
> This seems unpleasant and kind of painful. What did I miss here?
> 
> Matthew.
> 
> static inline __attribute__((always_inline)) void
> <<<<<<< 8e29af8a2843b6342dbc72db43ac82c9d29695bf
> #ifdef RTE_NEXT_ABI
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t ptype)
> #else
> rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint16_t *dp, uint32_t flags)
> #endif

The new mbuf provides packet type instead of flags.
So the processing in this function is changed and the variable name is
different to reflect this.