From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: "Verma, Shally" <Shally.Verma@cavium.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Athreya, Narayana Prasad" <NarayanaPrasad.Athreya@cavium.com>,
"Challa, Mahipal" <Mahipal.Challa@cavium.com>,
"Sahu, Sunila" <Sunila.Sahu@cavium.com>,
"Sahu, Sunila" <Sunila.Sahu@cavium.com>,
"Gupta, Ashish" <Ashish.Gupta@cavium.com>
Subject: Re: [dpdk-dev] [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue
Date: Tue, 24 Jul 2018 07:53:57 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8977F8FFE68@IRSMSX107.ger.corp.intel.com> (raw)
In-Reply-To: <CY4PR0701MB3634967469199E30E43E3CCCF0550@CY4PR0701MB3634.namprd07.prod.outlook.com>
> -----Original Message-----
> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
> Sent: Tuesday, July 24, 2018 8:45 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; Athreya, Narayana Prasad
> <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
> <Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Sahu,
> Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>
> Subject: RE: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue
>
>
>
> >-----Original Message-----
> >From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >Sent: 24 July 2018 03:55
> >To: Verma, Shally <Shally.Verma@cavium.com>
> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
> ><NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
> ><Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
> >Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish
> ><Ashish.Gupta@cavium.com>
> >Subject: RE: [PATCH v4 4/5] compress/zlib: support burst
> >enqueue/dequeue
> >
> >External Email
> >
> >> -----Original Message-----
> >> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> >> Sent: Monday, July 23, 2018 3:51 PM
> >> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> >> mchalla@caviumnetworks.com; Sunila Sahu <ssahu@caviumnetworks.com>;
> >> Sunila Sahu <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> >> <ashish.gupta@caviumnetworks.com>
> >> Subject: [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue
> >>
> >> From: Sunila Sahu <ssahu@caviumnetworks.com>
> >>
> >> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> >> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> >> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> >> ---
> >> drivers/compress/zlib/zlib_pmd.c | 255
> >> ++++++++++++++++++++++++++++++++++++++-
> >> 1 file changed, 254 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/compress/zlib/zlib_pmd.c
> >> b/drivers/compress/zlib/zlib_pmd.c
> >> index 47bc73d..dc1e230 100644
> >> --- a/drivers/compress/zlib/zlib_pmd.c
> >> +++ b/drivers/compress/zlib/zlib_pmd.c
> >> @@ -7,7 +7,214 @@
> >>
> >> #include "zlib_pmd_private.h"
> >>
> >> -/** Parse comp xform and set private xform/stream parameters */
> >> +/** Compute next mbuf in the list, assign data buffer and length,
> >> + * returns 0 if mbuf is NULL
> >> + */
> >> +#define COMPUTE_BUF(mbuf, data, len) \
> >> + ((mbuf = mbuf->next) ? \
> >> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
> >> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
> >> +
> >> +static void
> >> +process_zlib_deflate(struct rte_comp_op *op, z_stream *strm) {
> >
> >...
> >
> >> + /* Update z_stream with the inputs provided by application */
> >> + strm->next_in = rte_pktmbuf_mtod_offset(mbuf_src, uint8_t *,
> >> + op->src.offset);
> >
> >This is assuming that src buffer is a linear buffer or that offset won't be large
> enough to cross boundaries between segments.
> >If an SGL is passed and offset is bigger than the first segment,
> >next_in should point at a different segment, with the remaining part of
> >the offset in that segment (look at ISA-L SGL patch:
> http://patches.dpdk.org/patch/43283/). Same applies to avail_in, next_out and
> avail_out.
>
> [Shally] as per my last knowledge, offset was expected to be belonging only to
> the first segment in chained mbuf. Isn't that the case anymore? Did I miss any
> update on its definition?
> We had added the logic earlier that you're suggesting but removed that later, as
> I understood clarification about offset falling into any segment is still pending.
>
According to the comments:
uint32_t offset;
/**< Starting point for compression or decompression,
* specified as number of bytes from start of packet in
* source buffer.
* This offset starts from the first segment
* of the buffer, in case the m_src is a chain of mbufs.
It says that the offset starts from the first segment, but not that
it is only applicable for the first segment.
>From my point of view, an SGL should be seen like a contiguous (linear) buffer,
so if the offset crosses multiple segments, it is still valid, as it is still part of the buffer.
Thanks,
Pablo
> Thanks
> Shally
next prev parent reply other threads:[~2018-07-24 7:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 14:51 [dpdk-dev] [PATCH v4 0/5] compress: add ZLIB compression PMD Shally Verma
2018-07-23 14:51 ` [dpdk-dev] [PATCH v4 1/5] compress/zlib: add ZLIB PMD Shally Verma
2018-07-23 21:58 ` De Lara Guarch, Pablo
2018-07-24 7:20 ` Verma, Shally
2018-07-23 14:51 ` [dpdk-dev] [PATCH v4 2/5] compress/zlib: add device PMD ops Shally Verma
2018-07-23 22:02 ` De Lara Guarch, Pablo
2018-07-24 7:27 ` Verma, Shally
2018-07-23 14:51 ` [dpdk-dev] [PATCH v4 3/5] compress/zlib: create private xform Shally Verma
2018-07-23 14:51 ` [dpdk-dev] [PATCH v4 4/5] compress/zlib: support burst enqueue/dequeue Shally Verma
2018-07-23 22:25 ` De Lara Guarch, Pablo
2018-07-24 7:44 ` Verma, Shally
2018-07-24 7:53 ` De Lara Guarch, Pablo [this message]
2018-07-24 8:14 ` Verma, Shally
2018-07-24 8:19 ` Verma, Shally
2018-07-23 14:51 ` [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide Shally Verma
2018-07-23 17:58 ` De Lara Guarch, Pablo
2018-07-23 18:00 ` Verma, Shally
2018-07-23 21:18 ` De Lara Guarch, Pablo
2018-07-24 5:32 ` Verma, Shally
2018-07-24 7:47 ` De Lara Guarch, Pablo
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=E115CCD9D858EF4F90C690B0DCB4D8977F8FFE68@IRSMSX107.ger.corp.intel.com \
--to=pablo.de.lara.guarch@intel.com \
--cc=Ashish.Gupta@cavium.com \
--cc=Mahipal.Challa@cavium.com \
--cc=NarayanaPrasad.Athreya@cavium.com \
--cc=Shally.Verma@cavium.com \
--cc=Sunila.Sahu@cavium.com \
--cc=dev@dpdk.org \
/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).