[dpdk-dev] difficulty w/ RTE_NEXT_ABI

Thomas Monjalon thomas.monjalon at 6wind.com
Sat Nov 21 11:44:20 CET 2015


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.


More information about the dev mailing list