From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Hall Subject: difficulty w/ RTE_NEXT_ABI Date: Sat, 21 Nov 2015 03:49:35 -0500 Message-ID: <20151121084935.GA24056@mhcomputing.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: dev@dpdk.org Return-path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id 6786F8D38 for ; Sat, 21 Nov 2015 09:49:38 +0100 (CET) Content-Disposition: inline List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 ======= rfc1812_process(struct ipv4_hdr *ipv4_hdr, uint32_t *dp, uint32_t flags) >>>>>>> examples: update examples to use 24 bit extended next hop {