From: "Verma, Shally" <Shally.Verma@cavium.com>
To: "Trahe, Fiona" <fiona.trahe@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Athreya, Narayana Prasad" <NarayanaPrasad.Athreya@cavium.com>,
"Challa, Mahipal" <Mahipal.Challa@cavium.com>
Subject: Re: [dpdk-dev] [RFC] Compression API in DPDK
Date: Fri, 10 Nov 2017 12:05:14 +0000 [thread overview]
Message-ID: <BY1PR0701MB11118D47AD529DD6BC036204F0540@BY1PR0701MB1111.namprd07.prod.outlook.com> (raw)
In-Reply-To: <348A99DA5F5B7549AA880327E580B435892BC309@IRSMSX101.ger.corp.intel.com>
> -----Original Message-----
> From: Trahe, Fiona [mailto:fiona.trahe@intel.com]
> Sent: 07 November 2017 16:54
> To: Verma, Shally <Shally.Verma@cavium.com>; dev@dpdk.org
> Cc: Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>;
> Challa, Mahipal <Mahipal.Challa@cavium.com>; Trahe, Fiona
> <fiona.trahe@intel.com>
> Subject: RE: [dpdk-dev] [RFC] Compression API in DPDK
>
> 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.
>
[Shally] Ok. However, I'm not sure how to use Intermediate bufs here as it is not requirement for us for this purpose.
So, it looks like It is very device specific requirement where some may not need it. So, I would suggest that API should propose a way to indicate if it's a requirement for specific device so that app can input it at config time. May be feature flag or capability.
Thanks
Shally
> ///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.
next prev parent reply other threads:[~2017-11-10 12:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 5:48 Verma, Shally
2017-11-07 11:24 ` Trahe, Fiona
2017-11-10 12:05 ` Verma, Shally [this message]
2017-11-20 6:43 ` Verma, Shally
2017-11-20 11:34 ` Trahe, Fiona
2017-11-20 11:49 ` Verma, Shally
-- strict thread matches above, loose matches on Subject: below --
2017-10-12 17:04 Trahe, Fiona
2017-10-17 6:55 ` shally verma
2017-10-17 14:40 ` Trahe, Fiona
2017-10-20 17:40 ` Verma, Shally
2017-11-02 19:16 ` Trahe, Fiona
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY1PR0701MB11118D47AD529DD6BC036204F0540@BY1PR0701MB1111.namprd07.prod.outlook.com \
--to=shally.verma@cavium.com \
--cc=Mahipal.Challa@cavium.com \
--cc=NarayanaPrasad.Athreya@cavium.com \
--cc=dev@dpdk.org \
--cc=fiona.trahe@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).