From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id C19321AF03 for ; Thu, 5 Oct 2017 22:06:20 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 05 Oct 2017 13:06:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,482,1500966000"; d="scan'208";a="320054950" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga004.fm.intel.com with ESMTP; 05 Oct 2017 13:06:18 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.248]) by IRSMSX152.ger.corp.intel.com ([169.254.6.87]) with mapi id 14.03.0319.002; Thu, 5 Oct 2017 21:06:18 +0100 From: "Mokhtar, Amr" To: Thomas Monjalon CC: "dev@dpdk.org" , "Macnamara, Chris" , "Power, Niall" Thread-Topic: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev) Thread-Index: AQHTHaidyFtCgYsXxUqHDbe8mN+d6KKVBQ4AgCp8YwCAFmCi0A== Date: Thu, 5 Oct 2017 20:06:17 +0000 Message-ID: <3D3765A8CDB52A4C8B410430AA19CB236EC352C8@IRSMSX104.ger.corp.intel.com> References: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> <1503668796-65832-2-git-send-email-amr.mokhtar@intel.com> <1572712.p5bSGzdYpA@xps> In-Reply-To: <1572712.p5bSGzdYpA@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjdjOTc1MmMtZTg4ZS00M2NlLTg1MzItZGU1NTMwZmZmYzM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IkFyb3pRSGRcLzJ3cUM2d2U5d05hdFlyNWVpVW5XSnYwS3pzbmlMQmFsQnB3PSJ9 x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev) 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, 05 Oct 2017 20:06:22 -0000 Hi Thomas, Kindly find my inline replies below.. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday 21 September 2017 15:35 > To: Mokhtar, Amr > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev) >=20 > 25/08/2017 15:46, Amr Mokhtar: > > This RFC describes a proposal for the Wireless Base Band Device > > (bbdev) in DPDK that abstracts HW accelerators based on FPGA and/or > > Fixed Function Accelerators that assist with LTE Physical Layer > > processing. Furthermore, it decouples the application from the > > compute-intensive wireless functions by abstracting their optimized lib= raries to > appear as virtual bbdev devices. > > This makes bbdev a common programming framework that enables the same > > application code to be run on different systems with a single software > > architecture and programming model. If the system has hardware > > accelerators, they will be used, but if the system does not have > > hardware accelerators, software implementations can be used. >=20 > Looks interesting. > When do you plan to send the first version? Initial release has been pushed out. Feel free to have a look.. http://dpdk.org/ml/archives/dev/2017-September/077027.html http://dpdk.org/ml/archives/dev/2017-September/077028.html http://dpdk.org/ml/archives/dev/2017-September/077029.html http://dpdk.org/ml/archives/dev/2017-September/077030.html http://dpdk.org/ml/archives/dev/2017-September/077031.html http://dpdk.org/ml/archives/dev/2017-September/077033.html http://dpdk.org/ml/archives/dev/2017-September/077032.html >=20 > The description done in this RFC is very complete and clear. Thanks I wil= l ask few > questions below. >=20 > I assume packets are mbuf and Rx/Tx is done by ethdev. Right? Right. >=20 > Did you think about the API required for inline processing (i.e. bbdev co= mbined > with ethdev Rx/Tx)? The current programming model is that ethdev is being used for input/output= and the bbdev is offloaded for lookaside acceleration. The inline processing topic sounds interesting, this is something we can lo= ok at in the future. Appreciate if you can share your thoughts in that regard. >=20 > [...] > > Other design approaches where considered during design selection phase > > like a wireless device interface is to have individual interfaces for > > each operation type within the LTE physical layer. This somewhat > > follows the cryptodev model, where the device interface can be used to > > perform a single class of operation type. However, it is difficult to > > map a device which performs multiple operations into this model. > > Consider the hardware accelerator that performs Rate (De)Matching, > > Turbo encoding/decoding (Turbo is a Forward Error Correction > > algorithm) and CRC handling. The device would have to register with > > three interfaces, and it would need three look-aside operations to do > > the processing (impacting performance). > > It is not correct to use it with a FEC (Forward Error Correction) > > device interface, as the device does more than that. Also, there is a > > wide range of FEC algorithms, many of which have no parameters or > > use-cases in common with Turbo (for example Reed-Solomon used in > > storage), so the usefulness of such an interface is questionable. >=20 > So you decided to dedicate an API to the wireless base band functions, wh= ich is a > functional split. > I think the cryptodev API is a different split: it is targetting all proc= essing which > falls into the crypto category. > Some crypto algorithms are associated to the wireless function, while oth= ers are > more generic. >=20 > It is very difficult to know how to split the scope of an API. The way we view this functional split is: - If it is a cryptographic function -> cryptodev - If it is a Wireless L1 function, or in other words, more related to sign= al processing (coding, scrambling, modulation, ...) -> bbdev > With the proposed scheme, if a wireless LTE device implements ZUC algorit= hm, > we will have to support it in a cryptodev PMD while having a bbdev PMD fo= r > other wireless functions. > Thoughts? ZUC stays a cryptographic algorithm, it should go to cryptodev. It's true t= hat ZUC is a crypto algorithm used in the mobile wireless domain, but it is not rel= ated to signal processing (Layer 1). bbdev is targeting all or some of those wireless L1 functions. >=20 > > The initial release of the bbdev includes CRC attachment, Turbo Coding > > and Rate (De)Matching supported in software. > > > > A device reports its capabilities when registering itself in the bbdev = framework. > > With the aid of this capabilities mechanism, an application can query > > devices to discover which operations within the LTE physical layer > > they are capable of performing. > > > > Turbo code software library can be added as a virtual device to > > simulate the functionality being performed by the HW in case it is not > > existent or in case the application needs to use the two flavors to > > suit different types of workloads, for example: short payloads to use > > software Turbo and the HW for larger payloads. This software library > > is not part of DPDK mainstream, but it can be downloaded from an extern= al > link and linked to DPDK at compile time. >=20 > Do you mean that you do not plan to integrate the SW fallback for the tur= bo > coding feature? We DO actually plan to support SW-fallback of Turbo FEC in bbdev. > Even if it is packaged separately, it could be integrated with bbdev API. Right. It is packaged separately and link-able to bbdev library. >=20 > [...] > > The application can query how many bbdevs were discovered by the EAL > > through > > rte_bbdev_count() and then knows the range of valid device IDs that > > can be used for further device interaction. >=20 > You must have an iterator macro to be able to manage id range with holes. > I see it is already implemented as RTE_BBDEV_FOREACH. Right. bbdev has the iterator macro. But, sequential (gapless) device IDs only are currently supported in the fi= rst release. >=20 > [...] > > rte_bbdev_enqueue_ops(dev_id, queue_id, **ops, num_ops) > > rte_bbdev_dequeue_ops(dev_id, queue_id, **ops, num_ops) > [...] > > > > **ops is an array of pointers to struct rte_bbdev_op structures which > > contain all the details needed by the device to perform a single operat= ion. > > As the bbdev interface supports different operation types (although > > individual devices may only support a subset of these), it contains a > > type field, and a union of parameters for each operation type. > > > > struct rte_bbdev_op { > > enum rte_bbdev_op_type type; > > union { > > void *generic; > > struct rte_bbdev_op_turbo_dec *turbo_dec; > > struct rte_bbdev_op_turbo_enc *turbo_enc; > > }; > > }; >=20 > I do not understand this part. > It seems you want only two generic function to perform processing. > I do not see the benefit. > It is usually easier to have one function per type of processing. >=20 Bbdev devices support Turbo encode and Turbo decode operations. Both have separate sets of parameters and different functionalities, but each queue is capable of doing either encode or decode (keep in mind that this freedom of choice is only applicable before the q gets configured= ). There is only one enqueue function for both enc/dec, and similarly one dequeue function for both. The pmd internally interprets its argument array of type "rte_bbdev_op" differently based on whether this q was set up for enc or dec. See this pseudo-code to give more projection of the idea: enqueue(struct rte_bbdev_queue_data *q_data, struct rte_bbdev_op *op) { void *queue =3D q_data->queue_private; struct pmd_prv_queue *q =3D queue; switch (q->type) { case RTE_BBDEV_OP_TURBO_ENC: struct rte_bbdev_op_turbo_enc *enc =3D op->turbo_enc; /* do encode */ encode(enc); break; case RTE_BBDEV_OP_TURBO_DEC: struct rte_bbdev_op_turbo_dec *dec =3D op->turbo_edec; /* do decode */ decode(dec); break; } Since an enqueue was received on a decode queue, then the union is interpre= ted as (rte_bbdev_op_turbo_dec), and vice versa for the encode (rte_bbdev_op_tu= rbo_enc). > I will continue the review with the code itself. Thanks!