Hi,
2015-09-24 22:10, Arnon Warshavsky:
> Moving from dpdk 1.5 to 2.0 we observed a PPS performance degradation of
> ~30%.
> After chasing this one for a while we found the problem:
>
> A) Between the 2 versions rte_mbuf was increased in size from 1 to 2 cache
> lines.
> B) The standard (non-vector) rx function does not perform a prefetch for
> the 2nd cache line of the mbuf (I see this bug exists in 2.1 as well) and
> it touches it setting the next pointer to NULL.
> I tested it in ixgbe, but it looks like it exists in all drivers in the
> *_rx_recv_pkts() and *_rx_recv_scattered_pkts() functions.
> Once added the prefetch for the 2nd line, we were back in our previous
> numbers.
>
> I believe this one slipped under the radar as the vector mode is now the
> default.
> We stumbled into it because we work in non-vector mode due to a different
> mempool bug in 2.0 which sometimes crashes the application upon port stop.
Big thanks for this double bug report!
> I have 2 questions
> 1)
> Could anyone tell if the regression tests are comparing performance while
> building DPDK with the default set of flags alone, or are multiple options
> examined?
There is no official regression test of performance.
Though Intel is probably monitoring it for their hardware.
By the way, it would be a good improvement to have such standard benchmark
in DTS or elsewhere.
> 2)
> How are issues like that being tracked and later associated to a patch?
In general, it is followed by discussion and a patch on this mailing list.
The patch must track the fixed issue in the release notes.
In order to give better exposure of current bugs we could instantiate a
bug tracker. I think it's time to think about it seriously. Let's discuss
about the possible solutions in another thread.
Thanks again to you and all the Qwilt team.
PS: it would be nice to hear about your DPDK deployment and results
