Re: rte_pktmbuf_free_bulk vs rte_pktmbuf_free

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 11 Jan 2022 13:12:24 +0100
Filip Janiszewski <contact@filipjaniszewski.com> wrote:

> Hi,
> 
> Is there any specific reason why using rte_pktmbuf_free_bulk seems to be
> much slower than rte_pktmbuf_free in a loop? (DPDK 21.11)
> 
> I ran a bunch of tests on a 50GbE link where I'm getting packet drops
> (running with too few RX cores on purpose, to make some performance
> verification) and when the time comes to release the packets, i did a
> quick change like this:
> 
> .
>             //rte_pktmbuf_free_bulk( data, pkt_cnt );
>             for( idx = 0 ; idx < pkt_cnt ; ++idx ) {
>                 rte_pktmbuf_free( data[ idx ] );
>             }
> .
> 
> And suddenly I'm dropping around 10% less packets (The traffic rate is
> around ~95Mpps). In case that's relevant, RX from the nic is done on a
> separate core than where the pkts are released (processed and released)
> 
> I did also the following experiment: Found the MPPs speed value where i
> get around 2-5% drops using rte_pktmbuf_free_bulk, executed a bunch of
> readings where I consistently get drops.. Then switched to the loop with
> rte_pktmbuf_free and executed the same tests again, of a sudden I can't
> drop anymore.
> 
> Isn't this strange? I was sure rte_pktmbuf_free_bulk would be kind of
> optimized for bulk releases so people don't have to loop themselves.
> 
> Thanks
> 

Is your mbuf pool close to exhausted? How big is your bulk size?
It might be with that with larger bulk sizes, the loop is giving packets
back that instantly get consumed by incoming packets. So either pool is almost
empty or the non-bulk is keeping packets in cache more.