[dpdk-dev] clang build failing in v2.0.0 from poisoned symbols

[dpdk-dev] clang build failing in v2.0.0 from poisoned symbols

[Matthew Hall]

Hi all,

I am getting some odd behavior compiling the DPDK v2.0.0 tag with clang:

/* deprecated options */
#pragma GCC poison RTE_MBUF_SCATTER_GATHER
#pragma GCC poison RTE_MBUF_REFCNT

In file included from dpdk/lib/librte_mbuf/rte_mbuf.c:58:

dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]

So I was reading about all of this and it was clear what poisoning is for, but 
it wasn't as clear what I should do about this error on the clang side. I 
tried searching the archive for "clang poison" but I didn't get much.

Any advice for this?

Thanks,
Matthew

Re: [dpdk-dev] clang build failing in v2.0.0 from poisoned symbols

[Matthew Hall]

On Thu, Jun 18, 2015 at 08:37:46PM -0700, Matthew Hall wrote:
> dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]

Hi all,

I finally figured out what happened. My older DPDK build configuration file 
had defined the poisoned macros to try to enable the features they used to 
cover, which had been obsoleted and/or replaced.

I am happy to be able to report that my app compiled with no changes once I 
rebased my locally tweaked DPDK onto the v2.0.0 tag... very impressive work... 
we might not be binary compatible but we definitely seem to be source 
compatible for my app at least. Considering most people use the static library 
this is not a bad state to start with I'd say.

Matthew.

Re: [dpdk-dev] clang build failing in v2.0.0 from poisoned symbols

[Bruce Richardson]

On Thu, Jun 18, 2015 at 09:31:02PM -0700, Matthew Hall wrote:
> On Thu, Jun 18, 2015 at 08:37:46PM -0700, Matthew Hall wrote:
> > dpdk/lib/librte_mbuf/rte_mbuf.h:68:20: error: poisoning existing macro [-Werror]
> 
> Hi all,
> 
> I finally figured out what happened. My older DPDK build configuration file 
> had defined the poisoned macros to try to enable the features they used to 
> cover, which had been obsoleted and/or replaced.
> 
> I am happy to be able to report that my app compiled with no changes once I 
> rebased my locally tweaked DPDK onto the v2.0.0 tag... very impressive work... 
> we might not be binary compatible but we definitely seem to be source 
> compatible for my app at least. Considering most people use the static library 
> this is not a bad state to start with I'd say.
> 
> Matthew.

Thank you. It's finally nice to get some good news about compatibility! :-)

Re: [dpdk-dev] DPDK v2.0.0 has different rte_eal_pci_probe() behavior

[Matthew Hall]

On Jun 19, 2015, at 3:15 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> Thank you. It's finally nice to get some good news about compatibility! :-)

Hi Bruce,

I did manage to find just one weird issue when I was trying to use the new DPDK v2.0.0. Previously I had code which was calling rte_eal_pci_probe() after rte_eal_init, rte_set_log_level, rte_mempool_create steps were completed, based on some of the sample applications. However it seems like the new code is calling this function itself inside of rte_eal_init.

So then the second call to it from my application raises some pretty odd errors and causes DPDK to terminate because it was one of the whitelisted PCI devices which is considered mandatory to succeed in the init process:

EAL: PCI device 0000:00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100e rte_em_pmd
EAL:   PCI memory mapped at 0x7ff0dc200000
PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x100e
EAL: PCI device 0000:00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100e rte_em_pmd
EAL:   PCI memory mapped at 0x7ff0dc220000
EAL: Error - exiting with code: 1
  Cause: Requested device 0000:00:09.0 cannot be used

I am not sure if it means I screwed up and wasn't doing it right in the first place and it was always incorrect to do it the way I did or if this is a behavior change that should be documented somewhere. Has anybody else seen this behavior?

Matthew.

Re: [dpdk-dev] DPDK v2.0.0 has different rte_eal_pci_probe() behavior

[Matthew Hall]

On Jun 21, 2015, at 3:54 PM, Tom Barbette <tom.barbette@ulg.ac.be> wrote:
> Application call to rte_eal_pci_probe() is not needed anymore since DPDK 1.8.
> 
> http://dpdk.org/ml/archives/dev/2014-September/005890.html
> 
> You were not wrong before, it is just a change in DPDK. I came across the same problem a few days ago.
> 
> Tom Barbette

So, we have a good practical example below about ABI compatibility.

The prototype and name of the rte_eal_pci_probe() was kept exactly the same, and it compiled fine with no change, but it fails at runtime because it causes a dual-init of all the PCI devices and hits a resource conflict in the process.

Thus it's important to remember you can break compatibility even if the ABI stays the same, if the APIs themselves don't behave the same over time...

Matthew.