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 83FCF1B3BE for ; Tue, 3 Oct 2017 17:17:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D0A5120A92; Tue, 3 Oct 2017 11:17:54 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Oct 2017 11:17:54 -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=j6j8M0kKsuNc4xn +cYAYskAhBECoNmd9sJssERpRHrQ=; b=Kbpm07bIxegS5Q4jhgauvN462wGpHb3 0JfQcjAhnf/KtX7w0WntfqXCauaaN1qtr73fi8zEvhiUHFFHqY28OA3tJU4ktf06 xBIpRnGeBjUfKI+EDQfCMcv+JVW+S4yL2RonSLEAoUlqwT0HPboESq5CB6JcoFkB H/ahc+XWO1xM= 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=j6j8M0kKsuNc4xn+cYAYskAhBECoNmd9sJssERpRHrQ=; b=XC2iggpU Lo/MrGTipG20p1mK9SOUPyYRxq+jEyY7eJFr47InLctP7E6B0PD4YnTuWvoGmDqi pm2xDvSbGylBfucwmbXlPu/mofiFmQskD+mn1WyxZqkD7RpUfHWNNqxzAic5uP2q 8Xlpqv1YY4cjyQjwAseK/zmCphcNSuQEDCcRLfgc3UHbM+wFxQoa80M25o1bmEkT yQM2iWVVU5aLVnzZZBnUfNX+SR7M3IfLCIvpUsM4udf7hxA1cXU9cMqU1R3b2yoI EyepM9C/YdV2QLxx90zXLm2ar1T7ba4bCnICoOth0sXLKcDXWcy8OV+ZYwCfrS2s pkwly/696gYViQ== X-ME-Sender: X-Sasl-enc: iWuSUxJ4+E2a9uX+2Yt25oKCOTT3hoRq6JGZSca7iwdZ 1507043874 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 860EF2418B; Tue, 3 Oct 2017 11:17:54 -0400 (EDT) From: Thomas Monjalon To: "Mokhtar, Amr" Cc: dev@dpdk.org, fbl@redhat.com, aconole@redhat.com, bluca@debian.org Date: Tue, 03 Oct 2017 17:17:53 +0200 Message-ID: <1887012.k95aipThBJ@xps> In-Reply-To: <3D3765A8CDB52A4C8B410430AA19CB236EC341D7@IRSMSX104.ger.corp.intel.com> References: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> <5517187.euiR5LjUcT@xps> <3D3765A8CDB52A4C8B410430AA19CB236EC341D7@IRSMSX104.ger.corp.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: Tue, 03 Oct 2017 15:17:55 -0000 03/10/2017 16:29, Mokhtar, Amr: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 25/08/2017 15:46, Amr Mokhtar: > > > +int > > > +rte_bbdev_configure(uint8_t dev_id, uint16_t num_queues, > > > + const struct rte_bbdev_conf *conf); > > > > I am not convinced by the "configure all" function in ethdev. > > We break the ABI each time we add a new feature to configure. > > And it does not really help to have all configurations in one struct. > > Would you mind to split the struct rte_bbdev_conf and split the function > > accordingly? > > There is nothing to split tbh. The only parameter it has is the socket_id. > And in fact, it's optional, can be null. The only config we need is num_queues. Indeed, there is nothing in this struct. If you need only to allocate queues, you just have to rename this function. > I don't see in the near future that we may need to add more config params. > As a side, in the time of the implementation we were trying to avoid any > diversions from the current design ideology of ethdev and cryptodev. There is no ideology in ethdev, just some mistakes ;) > Can we leave it for consideration with future releases? No it should be addressed from the beginning. When you will need to add something more to configure port-wise, you should add a new function instead of breaking the ABI of the global conf struct. That's why the configure option should be more specialized. Distro people were complaining about ABI breakage last week. This is exactly an example of how to avoid it from the beginning. > > [...] > > > +struct __rte_cache_aligned rte_bbdev { > > > + rte_bbdev_enqueue_ops_t enqueue_ops; /**< Enqueue function */ > > > + rte_bbdev_dequeue_ops_t dequeue_ops; /**< Dequeue function */ > > > + const struct rte_bbdev_ops *dev_ops; /**< Functions exported by PMD > > */ > > > + struct rte_bbdev_data *data; /**< Pointer to device data */ > > > + bool attached; /**< If device is currently attached or not */ > > > > What "attached" means? > > I'm afraid you are trying to manage hotplug in the wrong layer. > > Hotplug is not supported in the current release. It is not answering the question. What is an "attached" device? > > [...] > > > +/** Structure specifying a single operation */ struct rte_bbdev_op { > > > + enum rte_bbdev_op_type type; /**< Type of this operation */ > > > + int status; /**< Status of operation that was performed */ > > > + struct rte_mempool *mempool; /**< Mempool which op instance is in > > */ > > > + void *opaque_data; /**< Opaque pointer for user data */ > > > + /** > > > + * Anonymous union of operation-type specific parameters. When > > allocated > > > + * using rte_bbdev_op_pool_create(), space is allocated for the > > > + * parameters at the end of each rte_bbdev_op structure, and the > > > + * pointers here point to it. > > > + */ > > > + RTE_STD_C11 > > > + union { > > > + void *generic; > > > + struct rte_bbdev_op_turbo_dec *turbo_dec; > > > + struct rte_bbdev_op_turbo_enc *turbo_enc; > > > + }; > > > +}; > > > > I am not sure it is a good idea to fit every operations > > in the same struct and the same functions. > > Due to the fact that our design adopts this idea that a device can support both > the encode and decode operations. > Then, at the time of PMD registration, the enqueue functions is allocated. > This enqueue() function is common for both operations. > This fitted operation structure is essential for the driver to decide on the operation. Sorry I do not understand why you must have a "generic operation". Please, could you try again to explain this design to someone not fully understanding how turbo enc/dec works?