From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id F3D961B194 for ; Thu, 21 Sep 2017 16:34:43 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A27E520BE4; Thu, 21 Sep 2017 10:34:43 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 21 Sep 2017 10:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+67yroqxwhCfpJP 4yHBsxnx/6+dRSn52WhwROy114pM=; b=HtQ8HgxHTzc8nD/Xe/LkviPhM3viRiz 60HHAGEn4SSwtNt6sHQ7NQE2dm+WiXlqqmdAKSfJ0PZ6aTVhce3qa4t39yWN83uj ErH80EmCkoONFSX5NFo1fERDb7GibRyJo7xbqa6h+isg4Ntyl+vWP342Kq18N9ZE gF1D3XLm+8Qg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=+67yroqxwhCfpJP4yHBsxnx/6+dRSn52WhwROy114pM=; b=b4VOKtdM pf5cbxPm6E3wO+4pCa6tTFClrB7oZfI6hJp0wVbjhU/iiK+aolLRHyH8YWHA6bmB r+XlBoXezbSVXZtV83+tjPaS6AUMgZf4iaqLpJ8qY6N4bih+tig3KFAv2GqRVvOt di0GJfQyBlVLUDSt5Bb8HBJhEpZLRaWlO++czs0A/Q0Qlpe4ybutqZMV6w6cbO9J 8NwHBFAJU1B3atDd57+cQ66GQQH4UHR1Wzco5ftLcb1ebUv1OMBf5mCJbkxdyrbU JQDQXsKXANbxUKBAxL1b2tj/H5bUZpZd6IaG1Vh+o9hLXwwybDnZSVDfXFSzJiz0 lxmR/msMZn0yqA== X-ME-Sender: X-Sasl-enc: ncUJ/XHSU9Qe5jP84KrEmnzEVe4c+FdDsBxl/frLii02 1506004483 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CC552473F; Thu, 21 Sep 2017 10:34:43 -0400 (EDT) From: Thomas Monjalon To: Amr Mokhtar Cc: dev@dpdk.org Date: Thu, 21 Sep 2017 16:34:42 +0200 Message-ID: <1572712.p5bSGzdYpA@xps> In-Reply-To: <1503668796-65832-2-git-send-email-amr.mokhtar@intel.com> References: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> <1503668796-65832-2-git-send-email-amr.mokhtar@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 21 Sep 2017 14:34:44 -0000 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 libraries 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. Looks interesting. When do you plan to send the first version? The description done in this RFC is very complete and clear. Thanks I will ask few questions below. I assume packets are mbuf and Rx/Tx is done by ethdev. Right? Did you think about the API required for inline processing (i.e. bbdev combined with ethdev Rx/Tx)? [...] > 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. So you decided to dedicate an API to the wireless base band functions, which is a functional split. I think the cryptodev API is a different split: it is targetting all processing which falls into the crypto category. Some crypto algorithms are associated to the wireless function, while others are more generic. It is very difficult to know how to split the scope of an API. With the proposed scheme, if a wireless LTE device implements ZUC algorithm, we will have to support it in a cryptodev PMD while having a bbdev PMD for other wireless functions. Thoughts? > 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 external link and linked to DPDK at compile time. Do you mean that you do not plan to integrate the SW fallback for the turbo coding feature? Even if it is packaged separately, it could be integrated with bbdev API. [...] > 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. 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. [...] > 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 operation. > 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; > }; > }; 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. I will continue the review with the code itself.