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.
