On Sun, Jan 08, 2017 at 03:15:00PM -0800, Stephen Hemminger wrote:
> On Fri, 6 Jan 2017 18:16:16 +0800
> Yuanhan Liu <yuanhan....@linux.intel.com> wrote:
>
> > If the primary enables the vector Rx/Tx path, the current code would
> > let the secondary always choose the non vector Rx/Tx path. This results
> > to a Rx/Tx method mismatch between primary and secondary process. Werid
> > errors then may happen, something like:
> >
> > PMD: virtio_xmit_pkts() tx: virtqueue_enqueue error: -14
> >
> > Fix it by choosing the correct Rx/Tx callbacks for the secondary process.
> > That is, use vector path if it's given.
> >
> > Fixes: 8d8393fb1861 ("virtio: pick simple Rx/Tx")
> >
> > Cc: sta...@dpdk.org
> > Signed-off-by: Yuanhan Liu <yuanhan....@linux.intel.com>
>
> This is failing on intel compile tests.
>
>
> http://dpdk.org/patch/18975
Thanks, but it looks like a false alarm to me, for reasons below.
> Failed Build #2:
> OS: RHEL7.2_64
> Target: x86_64-native-linuxapp-gcc
> MKRES test_resource_c.res.o
> /home/patchWorkOrg/compilation/x86_64-native-linuxapp-gcc/lib/librte_ethdev.a(rte_ethdev.o):
> In function `rte_eth_dev_pci_probe':
> rte_ethdev.c:(.text+0x9c4): undefined reference to `eth_dev_attach_secondary'
> collect2: error: ld returned 1 exit status
- eth_dev_attach_secondary is not defined in this patch, it's defined
(and used) in the first patch.
- eth_dev_attach_secondary is actually defined; The report even shows
it fails to build with gcc: the gcc build passes on my dev box.
Honestly, I seldom trusted the build reports from STV.
--yliu
