From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C3EBAA0524; Wed, 14 Apr 2021 02:44:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97D87160D2E; Wed, 14 Apr 2021 02:44:26 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id C4191160B1C for ; Wed, 14 Apr 2021 02:44:23 +0200 (CEST) IronPort-SDR: G4BId2H4IaJChvI/p+o/7pmPpg5V1VunI1AfhOd3hLii4sP7m2FA64FprhBz3o1IgfPV8WXeuB z/cahhwsgJgg== X-IronPort-AV: E=McAfee;i="6200,9189,9953"; a="192409032" X-IronPort-AV: E=Sophos;i="5.82,220,1613462400"; d="scan'208";a="192409032" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 17:44:22 -0700 IronPort-SDR: EDnVrzWz0wighIdVpk4cDzFvCPombxGb703rj3GNjXI/aNjSAvqWqbSEUW9H8lUWrUFTrljmKN XCDN3mWMRZXg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,220,1613462400"; d="scan'208";a="450605042" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by FMSMGA003.fm.intel.com with ESMTP; 13 Apr 2021 17:44:19 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 13 Apr 2021 17:44:19 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 13 Apr 2021 17:44:19 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Tue, 13 Apr 2021 17:44:19 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.101) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Tue, 13 Apr 2021 17:44:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gmHI3f8mcAf5Z6vv28zaaAxaJNL5XLv7cML6vwlBChHYGgmbiMlP6zAPlwUVPDvTAPag20d9fKwK8etoQ2iKKT7VxW07fAj9qt/eauteqNrmLt2xfMpi+gP9kftwep4M5egwRVKADmY1LOBxKKeGcfkRykpfDGUMKJqNZ5h1KwiYHdk6S/s+2H6BjjYsTVQWuZfJRUtZ4gAQjvCRWAonCL16kQfG2OMP6z0msV7CAG+czUjaHV3EGfUJGvF2oFJuR3boy/cIL+idtwZzPJwD6HA2n8Fumc7fdrZp8p3V6ClgvJ6HmPVTfo88yWmBZBFYD9+NAIMbsSVyG2Fj9AJ51w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EwwFz/5O7uHbUe8KTVd0Ct2Il2sw/wfP4p1BUOqrtuY=; b=h/K+/7kwzeZJiJdeLWGUfDoTLHsZXvLxwmjNvy29jB8YVv1VLbXkj3tAXr2V8+n1E7Axc+UwleMtHt/JmFZxeGdnRpjjsHg2RqSg0D6RQyQ+nHBEUD9N1uSCc3EekdFTx2fisztBX+CeBUvUFdshMFXe6FvevEi0NvuocXDUzOlfe+4o+kTYSppLskoEp/JVy6eIWwetWMND9KDmkTJVXYZkdTxSGRXh5PUAFKOfGbj3csDnPD4FYYvi9pC4I/IyM1s5t6t9mpfZYksY5RO91295NjLMUQOWQasjUdgYrCMf0pvkt3JmxUd1SJYC+JGmfBwPMkZTeuqkGt1fQP4HIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EwwFz/5O7uHbUe8KTVd0Ct2Il2sw/wfP4p1BUOqrtuY=; b=uvoy29Pke7ENhYs2JWL9uvE/IE6NE3FWlL746vqtkEmSQxBboDUN8tcAwqFkHEfcgoOJJzNpNm8VR198/qDrth43LNN5Rb480cYYWvV43FPRj2JsKwjjKipJH3m1DqyaciD3ilLlstBn5ri/Q9T1NBcgbAc417FpmPmMC5LsUTU= Received: from BY5PR11MB4451.namprd11.prod.outlook.com (2603:10b6:a03:1cb::30) by SJ0PR11MB4957.namprd11.prod.outlook.com (2603:10b6:a03:2df::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Wed, 14 Apr 2021 00:44:15 +0000 Received: from BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::756a:2aef:40b1:11c8]) by BY5PR11MB4451.namprd11.prod.outlook.com ([fe80::756a:2aef:40b1:11c8%5]) with mapi id 15.20.4020.022; Wed, 14 Apr 2021 00:44:15 +0000 From: "Chautru, Nicolas" To: Hemant Agrawal , "dev@dpdk.org" , "gakhil@marvell.com" , "Richardson, Bruce" CC: Nipun Gupta Thread-Topic: [RFC][PATCH] bbdev: add raw operation support for additional offloads Thread-Index: AQHXMCISid4Z8420kUev9Nge61MW0aqzIeKg Date: Wed, 14 Apr 2021 00:44:15 +0000 Message-ID: References: <20210413050006.6579-1-hemant.agrawal@nxp.com> In-Reply-To: <20210413050006.6579-1-hemant.agrawal@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [45.28.143.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78c75ffd-7eed-4592-788b-08d8fede6de3 x-ms-traffictypediagnostic: SJ0PR11MB4957: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cCtyP9z2u+e3h7ymsc/Ha73qQcGWXOIS0L4/yGd5nYc9gCwrPPzgFcTeST1BkfBrZ7rvPgU9GnWVIVg+nq6bIlWegn25Yga69jRwU3SfjMKWm8Tpt73yXjcd89+bhiHn59wAPVpLbLrdpIzKourDHIp/7eR8Z7ayLBCRIeqtKTvcSywmtITwIgMmh+tqJAfFQgVluJDybc47cdEGbXpl+kFfMDKFCLBm0vhQ/zj7kFn1LBi235/UFtxhtyCHA4cdcjYBLDMis/gbLm4D+GzHJd4NFJWAwMuGcehTpH4UwX/LUmniWQ0BfyhP+IaMAvMTjJfnfvDIztZzF/cYNOr2Gf+ZwvxGieOKo0P7PQr4i2db6LvHGOGVYfDTYAnqvfwv5RjHkgzgSqX+TsXeYqZCoxL+PtFt1+ej519KPnaNlWCQFiZ0i+SkAkPhwlkRbxM9qDVl6q9ktJk9xmHDS7nJ0YqjgekAI2KcPTz7EgUh35EbhSRGT3xmMRSqAH9lNfl0hVrQ0Ig/QTXQUvz0eZ/K88iz+DxXInsRYJZ2r86Xf4jFryrxkXhqZ/JDpHgb7j+IyFor50gKZzuHlRpso/1xPgjPyVE7wYU4zsx5UxfCOeM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4451.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(136003)(346002)(376002)(86362001)(4326008)(64756008)(66446008)(8936002)(186003)(83380400001)(9686003)(33656002)(52536014)(66946007)(55016002)(30864003)(66476007)(478600001)(76116006)(316002)(110136005)(66556008)(8676002)(6506007)(7696005)(53546011)(26005)(71200400001)(5660300002)(122000001)(38100700002)(6636002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?I78dEtB7PPQZuEXYxu1tkOMsXeyyHvbsRPXMmAJJmX99FOR8P1KEqPiWuu98?= =?us-ascii?Q?YiMLiDbbtP1CAX6TsTCON+X0B3jK0Sfw+HUyfmdN5cQvme4ePk3f9VezWmdG?= =?us-ascii?Q?qpHYIgnIqkRv5s/cCzYpVWZ98xfNVJl5/I+bOP/pLgr1sH1wNabLJwbruntD?= =?us-ascii?Q?raKlOAww6UoYj0vohFdXJgHB9iIVvRtxHOz3w59Irr4n3AWdxwXcNGOizdaA?= =?us-ascii?Q?wvghj2uz0DJDVtYtZyG8+aXe5RC+xJ/qhYa0QEIDlZoR40ZgcVN3SNPZlG0i?= =?us-ascii?Q?S9PGw3VnvTz3wq31ZziGS/yAEF3aYWxMC+ml0PCPF0Vkg7sFQ2aOgF0wIRIH?= =?us-ascii?Q?2/PUdpNBh2AKhQiLiSP8iKsbtqWEr0U3D2bqPHpsb8xD3uOTMHriFtNgbhLO?= =?us-ascii?Q?zZP6rLhHXYwOVx0wD0DsXji4JXYW4JoXupzizFcAOwooGmLcrCsSBH0ICHh7?= =?us-ascii?Q?ZzEts3y6haj8sFAu/JNv7J3Wd41vgm9Wb4Csq/Kaw+4v/QPU31YlkgrG53WM?= =?us-ascii?Q?Jk7DaCFrQQKEWX/jPgpLv0xdbQLNVQU+9MkQWiIGY+rEvgrtg5uLosYF5ZEb?= =?us-ascii?Q?k3QiRzImp4Nx9a0KScY9sA3XSjoI9X2Y0DCy/xcalI1XVSG3lb08LXPC7CmG?= =?us-ascii?Q?Fp2O8eIhoaVoTn7i/WTbDAnsxrR4MlOlOC4JEFHGhNTc491HPkz8v/WlxtcT?= =?us-ascii?Q?IftM6+eJnsFOnFghFToJPVoWIswlMPVjoj+nurA2HSb6kzrkO0fxiX/0lF3H?= =?us-ascii?Q?NPu2wb7V2ZSYYav4mVB3rao/PfuGgpdycsGUvwoNnM7I9Iai7QS9TcoyKAXE?= =?us-ascii?Q?11lJipKjlOuFwS4VM4Z5BqnJIX+gLqoS7B70hjif3Ngb+MUQPmVOmS4cH24U?= =?us-ascii?Q?uWdRyHA0saL56UsmNCsokZI51KySpLJTw3m7VW+c4H2bFTjmZTERTQMi9Krx?= =?us-ascii?Q?8I/LbZ4QNByucK6bFnu98l73cD9PENDPSKXfKMJUk5AWs0qPqx06TDIq9KZj?= =?us-ascii?Q?Txq8sdWq718BMJ1Z0wDM6afBG6Al7i8r/9GM2g5WZuQElLuCllDw5M79Iy95?= =?us-ascii?Q?uaihXt9A6u3SDWNjA0QqmllheUHrF4ZSPswo51siA8qChfCHkE0aCFQnThOr?= =?us-ascii?Q?qGFxzO2Xuond+JTB7N2qKG4dOwBmPhOj6Q3TWkxETSzivJYNX0aISgmgUb3N?= =?us-ascii?Q?lYziZ9wFfqVYpQta8EadIflcFKGKDZIUcc0dxEDWPGjyqW4LX/Kb8cST9MuB?= =?us-ascii?Q?4Os7KoJyteytSZcbrGjMSSTTEkXbQRiSDBoJlP7IMBZOz/WqEvOKgcjrp5r7?= =?us-ascii?Q?0n5/kFe7YFBowWIIX4NnsynP?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4451.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78c75ffd-7eed-4592-788b-08d8fede6de3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2021 00:44:15.1524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: z/KBeaSK2n3N3C6t0sw8JqWuND10wJf3LOmI9IF1pMnt3VmTo+SF8IppicqKqZTQtiSexWMfSnSpSxCwPerDLcaqpniScyzf/maySARbor4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4957 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [RFC][PATCH] bbdev: add raw operation support for additional offloads X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Initial question from a quick look, If you need a raw driver, cannot this b= e done by existing rawdev driver? Why should that fall under bbdev then? > -----Original Message----- > From: Hemant Agrawal > Sent: Monday, April 12, 2021 10:00 PM > To: dev@dpdk.org; gakhil@marvell.com; Chautru, Nicolas > > Cc: Hemant Agrawal ; Nipun Gupta > > Subject: [RFC][PATCH] bbdev: add raw operation support for additional > offloads >=20 > The exisiting bbdev APIs are limited for the lookaside FEC offload only. >=20 > The modem/FPGA can do much more than just the FEC offload. This patch > extend the operation to userdefined raw parameters, where they can > offload more than just the FEC offload processing. e.g. some of the devic= es > are capable of offloading large part of ORAN High-phy processing as well. >=20 > Signed-off-by: Nipun Gupta > Signed-off-by: Hemant Agrawal > --- > lib/librte_bbdev/rte_bbdev.c | 1 + > lib/librte_bbdev/rte_bbdev.h | 64 +++++++++++++++++++++ > lib/librte_bbdev/rte_bbdev_op.h | 98 +++++++++++++++++++++++---------- > 3 files changed, 134 insertions(+), 29 deletions(-) >=20 > diff --git a/lib/librte_bbdev/rte_bbdev.c b/lib/librte_bbdev/rte_bbdev.c > index 5ba891c232..9679048ce7 100644 > --- a/lib/librte_bbdev/rte_bbdev.c > +++ b/lib/librte_bbdev/rte_bbdev.c > @@ -1126,6 +1126,7 @@ rte_bbdev_op_type_str(enum > rte_bbdev_op_type op_type) > "RTE_BBDEV_OP_TURBO_ENC", > "RTE_BBDEV_OP_LDPC_DEC", > "RTE_BBDEV_OP_LDPC_ENC", > + "RTE_BBDEV_OP_RAW", > }; >=20 > if (op_type < RTE_BBDEV_OP_TYPE_COUNT) diff --git > a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbdev/rte_bbdev.h index > 7017124414..fe028524c8 100644 > --- a/lib/librte_bbdev/rte_bbdev.h > +++ b/lib/librte_bbdev/rte_bbdev.h > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: BSD-3-Clause > * Copyright(c) 2017 Intel Corporation > + * Copyright 2021 NXP > */ >=20 > #ifndef _RTE_BBDEV_H_ > @@ -387,6 +388,15 @@ struct rte_bbdev_queue_data { > bool started; /**< Queue state */ > }; >=20 > +/** @internal Enqueue encode operations for processing on queue of a > +device. */ typedef uint16_t (*rte_bbdev_enqueue_raw_op_t)( > + struct rte_bbdev_queue_data *q_data, > + struct rte_bbdev_raw_op *op); > + > +/** @internal Enqueue decode operations for processing on queue of a > +device. */ typedef struct rte_bbdev_raw_op > *(*rte_bbdev_dequeue_raw_op_t)( > + struct rte_bbdev_queue_data *q_data); > + > /** @internal Enqueue encode operations for processing on queue of a > device. */ typedef uint16_t (*rte_bbdev_enqueue_enc_ops_t)( > struct rte_bbdev_queue_data *q_data, > @@ -441,6 +451,10 @@ TAILQ_HEAD(rte_bbdev_cb_list, > rte_bbdev_callback); > * these fields, but should only write to the *_ops fields. > */ > struct __rte_cache_aligned rte_bbdev { > + /** Enqueue raw op function */ > + rte_bbdev_enqueue_raw_op_t enqueue_raw_op; > + /** Dequeue raw op function */ > + rte_bbdev_dequeue_raw_op_t dequeue_raw_op; > /** Enqueue encode function */ > rte_bbdev_enqueue_enc_ops_t enqueue_enc_ops; > /** Enqueue decode function */ > @@ -469,6 +483,33 @@ struct __rte_cache_aligned rte_bbdev { > /** @internal array of all devices */ > extern struct rte_bbdev rte_bbdev_devices[]; >=20 > +/** > + * Enqueue a RAW operation to a queue of the device. > + * If confirmation is required then the memory for the "op" structure > +should > + * be allocated from heap/mempool and should be freed only after > confirmation. > + * Otherwise, it shall be on stack or if on heap, should be freed after > +enqueue > + * operation. > + * > + * @param dev_id > + * The identifier of the device. > + * @param queue_id > + * The index of the queue. > + * @param op > + * Pointer containing operation to be enqueued. > + * > + * @return > + * Status of the enqueue operation. > + */ > +__rte_experimental > +static inline uint16_t > +rte_bbdev_enqueue_raw_op(uint16_t dev_id, uint16_t queue_id, > + struct rte_bbdev_raw_op *op) > +{ > + struct rte_bbdev *dev =3D &rte_bbdev_devices[dev_id]; > + struct rte_bbdev_queue_data *q_data =3D &dev->data- > >queues[queue_id]; > + return dev->enqueue_raw_op(q_data, op); } > + > /** > * Enqueue a burst of processed encode operations to a queue of the > device. > * This functions only enqueues as many operations as currently possible > and @@ -593,6 +634,29 @@ rte_bbdev_enqueue_ldpc_dec_ops(uint16_t > dev_id, uint16_t queue_id, > return dev->enqueue_ldpc_dec_ops(q_data, ops, num_ops); } >=20 > +/** > + * Dequeue a raw operation. > + * For HOST->MODEM queues, this would provide RAW op which had > + * "conf_enable" configured at queue initialization. > + * For MODEM->HOST queues, this would provide RAW op which are sent > from MODEM. > + * "op" memory would be internally allocated > + * > + * @param dev_id > + * The identifier of the device. > + * @param queue_id > + * The index of the queue. > + * > + * @return > + * Pointer containing dequeued operation. > + */ > +__rte_experimental > +static inline struct rte_bbdev_raw_op * > +rte_bbdev_dequeue_raw_op(uint16_t dev_id, uint16_t queue_id) { > + struct rte_bbdev *dev =3D &rte_bbdev_devices[dev_id]; > + struct rte_bbdev_queue_data *q_data =3D &dev->data- > >queues[queue_id]; > + return dev->dequeue_raw_op(q_data); > +} >=20 > /** > * Dequeue a burst of processed encode operations from a queue of the > device. > diff --git a/lib/librte_bbdev/rte_bbdev_op.h > b/lib/librte_bbdev/rte_bbdev_op.h index f726d7302e..fa993c6222 100644 > --- a/lib/librte_bbdev/rte_bbdev_op.h > +++ b/lib/librte_bbdev/rte_bbdev_op.h > @@ -1,5 +1,6 @@ > /* SPDX-License-Identifier: BSD-3-Clause > * Copyright(c) 2017 Intel Corporation > + * Copyright 2021 NXP > */ >=20 > #ifndef _RTE_BBDEV_OP_H_ > @@ -211,36 +212,57 @@ enum rte_bbdev_op_ldpcenc_flag_bitmasks { >=20 > /** Data input and output buffer for BBDEV operations */ struct > rte_bbdev_op_data { > - /** The mbuf data structure representing the data for BBDEV > operation. > - * > - * This mbuf pointer can point to one Code Block (CB) data buffer or > - * multiple CBs contiguously located next to each other. > - * A Transport Block (TB) represents a whole piece of data that is > - * divided into one or more CBs. Maximum number of CBs can be > contained > - * in one TB is defined by > RTE_BBDEV_(TURBO/LDPC)_MAX_CODE_BLOCKS. > - * > - * An mbuf data structure cannot represent more than one TB. The > - * smallest piece of data that can be contained in one mbuf is one > CB. > - * An mbuf can include one contiguous CB, subset of contiguous CBs > that > - * are belonging to one TB, or all contiguous CBs that are belonging > to > - * one TB. > - * > - * If a BBDEV PMD supports the extended capability "Scatter-Gather", > - * then it is capable of collecting (gathering) non-contiguous > - * (scattered) data from multiple locations in the memory. > - * This capability is reported by the capability flags: > - * - RTE_BBDEV_(TURBO/LDPC)_ENC_SCATTER_GATHER and > - * - RTE_BBDEV_(TURBO/LDPC)_DEC_SCATTER_GATHER. > - * Only if a BBDEV PMD supports this feature, chained mbuf data > - * structures are accepted. A chained mbuf can represent one > - * non-contiguous CB or multiple non-contiguous CBs. > - * If BBDEV PMD does not support this feature, it will assume > inbound > - * mbuf data contains one segment. > - * > - * The output mbuf data though is always one segment, even if the > input > - * was a chained mbuf. > + /** If set, this indicates that the memory pointer provided in > + * data or mem is a mempory pointer which is a contiguous memory > + * having the data (and is not a mbuf) > */ > - struct rte_mbuf *data; > + uint32_t is_direct_mem; > + union { > + /** The mbuf data structure representing the data for BBDEV > operation. > + * > + * This mbuf pointer can point to one Code Block (CB) data > buffer or > + * multiple CBs contiguously located next to each other. > + * A Transport Block (TB) represents a whole piece of data > that is > + * divided into one or more CBs. Maximum number of CBs > can be contained > + * in one TB is defined by > RTE_BBDEV_(TURBO/LDPC)_MAX_CODE_BLOCKS. > + * > + * An mbuf data structure cannot represent more than one > TB. The > + * smallest piece of data that can be contained in one mbuf is > one CB. > + * An mbuf can include one contiguous CB, subset of > contiguous CBs that > + * are belonging to one TB, or all contiguous CBs that are > belonging to > + * one TB. > + * > + * If a BBDEV PMD supports the extended capability "Scatter- > Gather", > + * then it is capable of collecting (gathering) non-contiguous > + * (scattered) data from multiple locations in the memory. > + * This capability is reported by the capability flags: > + * - RTE_BBDEV_(TURBO/LDPC)_ENC_SCATTER_GATHER and > + * - RTE_BBDEV_(TURBO/LDPC)_DEC_SCATTER_GATHER. > + * Only if a BBDEV PMD supports this feature, chained mbuf > data > + * structures are accepted. A chained mbuf can represent > one > + * non-contiguous CB or multiple non-contiguous CBs. > + * If BBDEV PMD does not support this feature, it will assume > inbound > + * mbuf data contains one segment. > + * > + * The output mbuf data though is always one segment, even > if the input > + * was a chained mbuf. > + */ > + struct rte_mbuf *data; > + > + /** bbuf representing the data for BBDEV operation. > + * This is a non scatter-gather buffer which uses length and > offset > + * parameters from rte_bbdev_op_data structure to evaluate > the > + * length of the buffer and offset of the starting data > respectively. > + */ > + void *bdata; > + > + /** memory pointer representing the data for BBDEV > operation. > + * This is a contiguous memory which uses length and offset > + * parameters from rte_bbdev_op_data structure to evaluate > the > + * length of the buffer and offset of the starting data > respectively. > + */ > + void *mem; > + }; > /** The starting point of the BBDEV (encode/decode) operation, > * in bytes. > * > @@ -738,6 +760,7 @@ enum rte_bbdev_op_type { > RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */ > RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */ > RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */ > + RTE_BBDEV_OP_RAW, /**< RAW operation */ > RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */ > }; >=20 > @@ -749,6 +772,23 @@ enum { > RTE_BBDEV_SYNDROME_ERROR > }; >=20 > +/** Structure specifying a single raw operation */ struct > +rte_bbdev_raw_op { > + /** RAW operation flags. BBDEV_RAW_OP_IN_VALID / > BBDEV_RAW_OP_OUT_VALID > + */ > + uint32_t raw_op_flags; > + /** Status of the operation */ > + uint32_t status; > + /** Opaque pointer for user data in case of confirmation. Invalid for > + * dequeue operation for MODEM -> HOST communication. > + */ > + void *opaque_data; > + /** Input data */ > + struct rte_bbdev_op_data input; > + /** Output data */ > + struct rte_bbdev_op_data output; > +}; > + > /** Structure specifying a single encode operation */ struct > rte_bbdev_enc_op { > /** Status of operation that was performed */ > -- > 2.17.1