[dpdk-dev] difficulty w/ RTE_NEXT_ABI

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

[dpdk-dev] [PATCH v3 1/6] szedata2: add new poll mode driver

2015-11-20 20:25, Matej Vido: > > As only 64-bit versions of the libraries are provided, I guess we > > could mention it is currently supported only on x86-64. > > I agree. Should I update the documentation and send a patch? Yes please. Another note: I use -rpath= in EXTRA_LDFLAGS to find the de

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

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] Making rte_eal_pci_probe() in rte_eal_init() optional?

David/Thomas, in-line -Roger On 11/18/15 5:13 PM, Roger B. Melton wrote: > Hi Thomas, in-line -Roger > > On 11/17/15 10:46 AM, Thomas Monjalon wrote: >> 2015-11-17 08:56, Roger B. Melton: >>> Hi David, in-line -Roger >>> >>> On 11/16/15 4:46 AM, David Marchand wrote: Hello Roger, >>

[dpdk-dev] difficulty w/ RTE_NEXT_ABI

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