[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-23 Thread Thomas Monjalon
2015-11-22 18:25, Matthew Hall: > On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote: > > > So again I am confused what advantage we got from RTE_NEXT_ABI here, and > > > how > > > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a > > > binary variable. > > >

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-22 Thread Matthew Hall
On Mon, Nov 23, 2015 at 01:13:32AM +0100, Thomas Monjalon wrote: > If your change is sent upstream, you must rely on the new ABI because the old > one > will be removed when your change will be integrated. > If it is a local change, it depends on which ABI you want to use. I submitted separately

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-22 Thread Thomas Monjalon
2015-11-21 19:25, Matthew Hall: > On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote: > > 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. > > But the data type of the variable

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-22 Thread Matthew Hall
On Sun, Nov 22, 2015 at 09:59:30PM +0100, Thomas Monjalon wrote: > > So again I am confused what advantage we got from RTE_NEXT_ABI here, and > > how > > you have multiple copies of RTE_NEXT_ABI on a single symbol when it is a > > binary variable. > > I don't understand what is not clear here.

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-21 Thread Matthew Hall
On Sat, Nov 21, 2015 at 11:44:20AM +0100, Thomas Monjalon wrote: > 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. But the data type of the variable is the same, and this is an internal alway

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-21 Thread Thomas Monjalon
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_in

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

2015-11-21 Thread 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 s