Hi Shally, ///snip/// > [Shally] Ok. Then, just to confirm my understanding here. You mean PMD can > figure out amount of > available space in dst mbuf by calling rte_pktmbuf_data_len() on each of its > segment? [Fiona] exactly.
///snip/// > > > > > > + * This indicates the buffer size and should be > > > > > > + * set a little larger than the expected max source buffer > > > > > > size. > > > > > > + * if the output of static compression doesn't fit in the > > > > > > + * intermediate buffer dynamic compression may not be > > > > > > possible, > > > > > > + * in this case the accelerator may revert back to static > > compression. > [Shally] > > > > + * in this case the accelerator may revert back to > static compression.> > > > > + */ > Can you elaborate more on this? This looks to me as decision made during > enqueue_burst() processing. > If yes and If application has chosen specific Huffman code i.e. > RTE_COMP_DYNAMIC or > RTE_COMP_FIXED in rte_comp_compress_xform, then how this would work? [Fiona] yes, it would have to revert back on the enqueue. The compressed data would still conform to deflate standard, so any decompressor would be able to inflate it. The ratio would not be as good as hoped for but it would be the best the compression engine could do with the resources it has. ///snip/// > [Shally] Sure. So just to align here. Except few questions posted above on > this RFC (such as Dynamic Vs > Static or dst mbuf parsing), following (and any other) will further be > covered as part of 'RFC doc' > discussion > - Hash support > - RTE_COMPDEV_FF_MULTI_PKT_CHECKSUM [Fiona] Agreed.
