From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0086.outbound.protection.outlook.com [104.47.38.86]) by dpdk.org (Postfix) with ESMTP id 025121B54E for ; Thu, 12 Jul 2018 07:46:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=snJywg+VDD7DYBv2jo/tyGJj6g8ghsK1VGD94GGqazg=; b=Q+kwmBjaRj7ycqmLw86tjW36gcTZ7b4wrqIoV/iN0awfc2X+zyxkLwTv7wREFbNrAYiRZkPoYcWYFeAqXtP1bw+PS636KxdkUpXEIGLv8/YE9rh08COjUH7v31aoRazWNWvCXBG6oH4LdggIs71pNUJ/9zspNxBZYxCKVItu4q8= Received: from CY4PR0701MB3634.namprd07.prod.outlook.com (52.132.101.164) by CY4PR0701MB3826.namprd07.prod.outlook.com (52.132.102.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Thu, 12 Jul 2018 05:46:21 +0000 Received: from CY4PR0701MB3634.namprd07.prod.outlook.com ([fe80::f0d4:1828:37f5:5927]) by CY4PR0701MB3634.namprd07.prod.outlook.com ([fe80::f0d4:1828:37f5:5927%2]) with mapi id 15.20.0930.022; Thu, 12 Jul 2018 05:46:20 +0000 From: "Verma, Shally" To: "De Lara Guarch, Pablo" CC: "dev@dpdk.org" , "Athreya, Narayana Prasad" , "Challa, Mahipal" , "Sahu, Sunila" , "Sahu, Sunila" , "Gupta, Ashish" Thread-Topic: [PATCH v2 4/5] compress/zlib: add enq deq apis Thread-Index: AQHUGRqw12RJ58/4uEOad48fOMZ8CKSKDncA Date: Thu, 12 Jul 2018 05:46:20 +0000 Message-ID: References: <1530550631-22841-1-git-send-email-shally.verma@caviumnetworks.com> <1530550631-22841-5-git-send-email-shally.verma@caviumnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shally.Verma@cavium.com; x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR0701MB3826; 7:K3k4NOcry2eswBheYPYcXF4qWyp3hDrheyougt16+rWG3GLT0pPH+FZprwTn2zSxb2+FxbAUI2x7BChoofcHOqQefvWJY256XJ3UsjCjHLOGgBwqQDADoHlicf5BnGoPrsYD3L426ow2V/CVDu9sqliOuQFtzihH86vlbRbI02VmBj4YMXNsb3SZ7s7xRZLYcjNc1LFeEWHPgn5y0sYMCICeY2LqZ1iTgUoi4jDKnkW70Dt/bDp7ksOyHKjz4xKh x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(396003)(39860400002)(199004)(189003)(13464003)(6246003)(66066001)(14444005)(478600001)(72206003)(86362001)(186003)(6916009)(5660300001)(256004)(54906003)(107886003)(5250100002)(26005)(99286004)(25786009)(102836004)(68736007)(53936002)(4326008)(316002)(14454004)(2906002)(55236004)(6116002)(6436002)(2900100001)(3846002)(7736002)(305945005)(74316002)(476003)(33656002)(6506007)(53546011)(81166006)(105586002)(8676002)(9686003)(8936002)(55016002)(229853002)(81156014)(76176011)(7696005)(486006)(106356001)(97736004)(11346002)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR0701MB3826; H:CY4PR0701MB3634.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: 6f96fa2e-ce9e-47c4-1a08-08d5e7bacb89 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CY4PR0701MB3826; x-ms-traffictypediagnostic: CY4PR0701MB3826: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY4PR0701MB3826; BCL:0; PCL:0; RULEID:; SRVR:CY4PR0701MB3826; x-forefront-prvs: 0731AA2DE6 received-spf: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ALQwEkoL3+DPXrexw0tqB+yHdCQ/7b0wms2aduZuY5fkF6LYaDASUUeyZVLZpzzsx7pw5+UfXRj4yIzHCDpqLfzFaTn/x6pMFm+9pTvIeoD3/y9oBmdbMiKiJBRdzBJ+aeeuWiL2n0e78wHmINJ6O+5PBc0wjZxA0K2mfX/pFzcTqkNoQog/MvgIg1gdfjwZ+6OB45+iFNDyyK5oPA8PkgHUuBXHXbwNLoHKzjLgJMBP38E3GncVlQvi7aE1Ey9WMKjxjwz51uEtUNM2h03LIVsxjj3oqV6rmD+UZfskWda0HFQZMcN2/UrnsRG90WGIMbywoPtm82dsDNz+Ams9XD1BgaURcQeXbacfA/jSvTw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f96fa2e-ce9e-47c4-1a08-08d5e7bacb89 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2018 05:46:20.6236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3826 Subject: Re: [dpdk-dev] [PATCH v2 4/5] compress/zlib: add enq deq apis X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 05:46:26 -0000 >-----Original Message----- >From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com] >Sent: 11 July 2018 18:56 >To: Verma, Shally >Cc: dev@dpdk.org; Athreya, Narayana Prasad ; Challa, Mahipal >; Sahu, Sunila ; Sahu, = Sunila ; Gupta, Ashish > >Subject: RE: [PATCH v2 4/5] compress/zlib: add enq deq apis > >External Email > >Hi, > >> -----Original Message----- >> From: Shally Verma [mailto:shally.verma@caviumnetworks.com] >> Sent: Monday, July 2, 2018 5:57 PM >> To: De Lara Guarch, Pablo >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com; >> mchalla@caviumnetworks.com; Sunila Sahu ; >> Sunila Sahu ; Ashish Gupta >> >> Subject: [PATCH v2 4/5] compress/zlib: add enq deq apis > >Better retitle to "support burst enqueue/dequeue". > >> >> From: Sunila Sahu >> >> implement enqueue and dequeue apis > >This should start with capital letter, but this is probably not needed any= way. > >> >> Signed-off-by: Sunila Sahu >> Signed-off-by: Shally Verma >> Signed-off-by: Ashish Gupta >> --- >> drivers/compress/zlib/zlib_pmd.c | 238 >> ++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 237 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/compress/zlib/zlib_pmd.c b/drivers/compress/zlib/zl= ib_pmd.c >> index 7c2614e..aef23de 100644 >> --- a/drivers/compress/zlib/zlib_pmd.c >> +++ b/drivers/compress/zlib/zlib_pmd.c >> @@ -6,7 +6,198 @@ >> #include >> #include "zlib_pmd_private.h" >> >> -/** Parse comp xform and set private xform/stream parameters */ >> +/** Compute next mbuf in the list, assign data buffer and len */ >> +#define COMPUTE_BUF(mbuf, data, len) \ >> + ((mbuf =3D mbuf->next) ? \ >> + (data =3D rte_pktmbuf_mtod(mbuf, uint8_t *)), \ >> + (len =3D rte_pktmbuf_data_len(mbuf)) : 0) >> + >> +/** Set op->status to appropriate flag if we run out of mbuf */ >> +#define COMPUTE_DST_BUF(mbuf, dst, dlen) \ >> + ((COMPUTE_BUF(mbuf, dst, dlen)) ? 1 : \ >> + (!(op->status =3D \ > >I see and build error here: > >drivers/compress/zlib/zlib_pmd.c(81): error #187: use of "=3D" where "=3D= =3D" may have been intended > COMPUTE_DST_BUF(mbuf_dst, strm->next_out, >It is a bit confusing macro, but afaik, you should pass op if you want to = modify the status >(I suggest making this more readable). > > >> + RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED))) >> + >> +static void >> +process_zlib_deflate(struct rte_comp_op *op, z_stream *strm) { >> + int ret, flush, fin_flush; >> + struct rte_mbuf *mbuf_src =3D op->m_src; >> + struct rte_mbuf *mbuf_dst =3D op->m_dst; >> + >> + switch (op->flush_flag) { >> + case RTE_COMP_FLUSH_FULL: >> + case RTE_COMP_FLUSH_FINAL: >> + fin_flush =3D Z_FINISH; >> + break; >> + default: >> + op->status =3D RTE_COMP_OP_STATUS_INVALID_ARGS; >> + ZLIB_PMD_ERR("\nInvalid flush value"); > >Better to have "\n" at the end for consistency. > >> + >> + } >> + >> + if (unlikely(!strm)) { >> + op->status =3D RTE_COMP_OP_STATUS_INVALID_ARGS; >> + ZLIB_PMD_ERR("\nInvalid z_stream"); >> + return; >> + } >> + /* Update z_stream with the inputs provided by application */ >> + strm->next_in =3D rte_pktmbuf_mtod_offset(mbuf_src, uint8_t *, >> + op->src.offset); >> + >> + strm->avail_in =3D rte_pktmbuf_data_len(mbuf_src) - op->src.offset= ; > >Shouldn't this be "op->src.length"? If packet is segmented, then src.length will give wrong o/p. Though we are = not claiming segmented packet support. But this is safer way to do. > >> + >> + strm->next_out =3D rte_pktmbuf_mtod_offset(mbuf_dst, uint8_t *, >> + op->dst.offset); >> + >> + strm->avail_out =3D rte_pktmbuf_data_len(mbuf_dst) - op->dst.offse= t; >> + >> + /* Set flush value to NO_FLUSH unless it is last mbuf */ >> + flush =3D Z_NO_FLUSH; >> + /* Initialize status to SUCCESS */ >> + op->status =3D RTE_COMP_OP_STATUS_SUCCESS; >> + > >... > >> + /* Update source buffer to next mbuf >> + * Exit if op->status is not SUCCESS or input buffers are fully co= nsumed >> + */ >> + } while ((op->status =3D=3D RTE_COMP_OP_STATUS_SUCCESS) && >> + (COMPUTE_BUF(mbuf_src, strm->next_in, strm->avail_in))); > >It looks like you support Scatter Gather here, but according to the docume= ntation, you don't support it... > Yes. right now, we don't claim its support as we couldn't test it. >> + >> +def_end: >> + /* Update op stats */ >> + switch (op->status) { >> + case RTE_COMP_OP_STATUS_SUCCESS: >> + op->consumed +=3D strm->total_in; > >I see a compilation error with gcc: > >drivers/compress/zlib/zlib_pmd.c:166:16: error: >this statement may fall through [-Werror=3Dimplicit-fallthrough=3D] > op->consumed +=3D strm->total_in; > ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ >drivers/compress/zlib/zlib_pmd.c:167:2: note: here > case RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED: > ^~~~ > >If the intention is to fall-through, you should add a comment before the n= ext case. > Ok. But then my view is it shouldn't be taken as error here. Is it we don't= want fall-through model? >> + case RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED: >> + op->produced +=3D strm->total_out; >> + break; >> + default: >> + ZLIB_PMD_ERR("stats not updated for status:%d\n", >> + op->status); >> + } >> + >> + deflateReset(strm); >> +} >> + > >... > >> + >> +/** Process comp operation for mbuf */ >> +static inline int >> +process_zlib_op(struct zlib_qp *qp, struct rte_comp_op *op) { >> + struct zlib_stream *stream; >> + >> + if ((op->op_type =3D=3D RTE_COMP_OP_STATEFUL) || >> + op->src.offset > rte_pktmbuf_data_len(op->m_src) || >> + op->dst.offset > rte_pktmbuf_data_len(op->m_dst)) { > >An extra indentation is needed, so it is easy to distinguish between the i= f statement and the body. >You should also check if (src.offset + src.length > rte_pktmbuf_data_len(o= p->m_src)) Should it be checked against pktmbuf_data_len() or pktmbuf_pkt_len()?! > >> + op->status =3D RTE_COMP_OP_STATUS_INVALID_ARGS; >> + ZLIB_PMD_ERR("\nInvalid source or destination buffers or " >> + "invalid Operation requested"); > >Better to include the "\n" at the end. > >> + } else { >> + stream =3D &((struct zlib_priv_xform *)op->private_xform)- >> >stream; > >I think it is more readable to have this line split into two: >First get the private xform and then get zlib_stream pointer. > >> + stream->comp(op, &stream->strm); >> + } >> + /* whatever is out of op, put it into completion queue with >> + * its status >> + */ >> + return rte_ring_enqueue(qp->processed_pkts, (void *)op); } >> + > >... > >> +static uint16_t >> +zlib_pmd_enqueue_burst(void *queue_pair, >> + struct rte_comp_op **ops, uint16_t nb_ops) { >> + struct zlib_qp *qp =3D queue_pair; >> + int ret, i; >> + int enqd =3D 0; > >"i" and "enqd" variables should be uint16_t. > >> + for (i =3D 0; i < nb_ops; i++) { >> + ret =3D process_zlib_op(qp, ops[i]); > >I think you should check if there is enough space in the ring for all the = operations, to save time. >If there is not, then the PMD would modify the operation unnecessarily and= waste a lot of time. >Then, with that check, you can just process the operations that can fit, l= ooping until minimum between >nb_ops and space available in the ring. I doubt if I should do that. If there's an application with dequeue only th= read, then at one point, we may see it=20 full and another space available. Since this PMD is using lockless rings, i= t can be made flexible to produce as many it can. > >> + if (unlikely(ret < 0)) { >> + /* increment count if failed to push to completion >> + * queue >> + */ >> + qp->qp_stats.enqueue_err_count++; > >I think this variable should be used when there was an error in the operat= ion but >it was still be enqueued (because there was space in the ring). >So you can increase this count in process_zlib_op when there is an error. > So what is exact purpose of this stat? is enqueue_err_count supposed to gi= ve number of failed operations in processed queue? Or, just number of operations that couldn't be enqueued/dequeued for proces= sing? >> + } else { >> + qp->qp_stats.enqueued_count++; > >I think this should be equal to all the operations enqueued (with and with= out error). Yes. Right now it does that except for the cases, where op couldn't be push= ed into as processing queue, and user cannot deque it. Thanks Shally > >> + enqd++; >> + } >> + } >> + return enqd; >> +}