Re: [dpdk-dev] [PATCH v1] app/crypto-perf: set mbuf lengths correctly for DOCSIS tests

["Coyle, David" <david.coyle@intel.com>]

Hi Pablo,

> -----Original Message-----
> From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Sent: Friday, July 17, 2020 8:04 PM
> > @@ -48,6 +48,10 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
> >  			} else
> >  				buf_sz = options->test_buffer_size;
> >
> > +			sym_op->m_src->buf_len = options->segment_sz;
> > +			sym_op->m_src->data_len = buf_sz;
> > +			sym_op->m_src->pkt_len = buf_sz;
> > +
> 
> Actually, I am wondering why this is needed at all (for DOCSIS and PDCP). This
> is already set in " fill_multi_seg_mbuf" or " fill_single_seg_mbuf" (and this
> was already working without this patch, right?).

[DC] I have found that if a number of buffer sizes are specified like this on the
cmd line "--buffer-sz 64,256,1024", then the pkt_len and data_len filled in
"fill_multi_seg_mbuf" or " fill_single_seg_mbuf" is always the largest of the
sizes specified. The cipher/auth lengths are then set based on the --buffer-sz
option.

For DOCSIS, I tried to be more accurate and set the correct pkt_len and data_len
in the mbuf. This followed what PDCP did too, even though I'm not sure of the
background why PDCP did it - possibly spotted the same issue. I have also found
that DOCSIS performance figures can be better if the correct pkt_len and data_len
are set in the mbuf - I don't have any proper explanation for this though as the cipher/
auth lengths are always the same.

I've dug around a bit more on this now though and this is actually a problem across
the perf tool. Some of the crypto PMDs have logic based on the mbuf pkt_len
and data_len, but because the perf tool isn't always setting these fields correctly,
that logic may not work as expected.
>