Hi Pablo, > -----Original Message----- > From: De Lara Guarch, Pablo <pablo.de.lara.gua...@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. >
