From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A60771B38C for ; Tue, 3 Oct 2017 16:29:52 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2017 07:29:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,474,1500966000"; d="scan'208";a="1178160639" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga001.jf.intel.com with ESMTP; 03 Oct 2017 07:29:49 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.248]) by IRSMSX109.ger.corp.intel.com ([169.254.13.28]) with mapi id 14.03.0319.002; Tue, 3 Oct 2017 15:29:49 +0100 From: "Mokhtar, Amr" To: "thomas@monjalon.net" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] Wireless Base Band Device (bbdev) Thread-Index: AQHTHaidyFtCgYsXxUqHDbe8mN+d6KK/h2qAgBK8FRA= Date: Tue, 3 Oct 2017 14:29:48 +0000 Message-ID: <3D3765A8CDB52A4C8B410430AA19CB236EC341D7@IRSMSX104.ger.corp.intel.com> References: <1503668796-65832-1-git-send-email-amr.mokhtar@intel.com> <5517187.euiR5LjUcT@xps> In-Reply-To: <5517187.euiR5LjUcT@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWMzNWMwOGMtN2VjYi00OTAxLWIwZjktYjY5MzM1OTA3NDQxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Inl0SkNqb1FmZjJ0ZGE2RFZ6bVY5WGxHOFF6Vm9peXlIZUFPY2RqUFczblE9In0= 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: Tue, 03 Oct 2017 14:29:53 -0000 Hi Thomas, Thanks for reviewing.. Kindly find my reply in-line below.. > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday 21 September 2017 15:56 > 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: > > +/** > > + * Configure a device. > > + * This function must be called on a device before setting up the > > +queues and > > + * starting the device. It can also be called when a device is in the > > +stopped > > + * state. If any device queues have been configured their > > +configuration will be > > + * cleared by a call to this function. > > + * > > + * @param dev_id > > + * The identifier of the device. > > + * @param num_queues > > + * Number of queues to configure on device. > > + * @param conf > > + * The device configuration. If NULL, a default configuration will b= e used. > > + * > > + * @return > > + * - 0 on success > > + * - EINVAL if num_queues is invalid, 0 or greater than maximum > > + * - EBUSY if the identified device has already started > > + * - ENOMEM if unable to allocate memory > > + */ > > +int > > +rte_bbdev_configure(uint8_t dev_id, uint16_t num_queues, > > + const struct rte_bbdev_conf *conf); >=20 > 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_que= ues. 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. Can we leave it for consideration with future releases? >=20 > [...] > > +struct rte_bbdev_info { > > + int socket_id; /**< NUMA socket that device is on */ > > + const char *dev_name; /**< Unique device name */ > > + const struct rte_pci_device *pci_dev; /**< PCI information */ > > + unsigned int num_queues; /**< Number of queues currently configured > */ > > + struct rte_bbdev_conf conf; /**< Current device configuration */ > > + bool started; /**< Set if device is currently started */ > > + struct rte_bbdev_driver_info drv; /**< Info from device driver */ > > +}; >=20 > As Stephen said, PCI must not appear in this API. > Please use the bus abstraction. Done. >=20 > [...] > > +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 */ >=20 > What "attached" means? > I'm afraid you are trying to manage hotplug in the wrong layer. Hotplug is not supported in the current release. >=20 > > + struct rte_device *device; /**< Backing device (HW only) */ >=20 > SW port should have also a rte_device (vdev). Right. Fixed the comment. >=20 > [...] > > +/** Data input and output buffer for Turbo operations */ struct > > +rte_bbdev_op_data { >=20 > Why there is no "turbo" word in the name of this struct? To keep it a generic input/output data descriptor, that suits any type of baseband operation not only for turbo. >=20 > > + struct rte_mbuf *data; > > + /**< First mbuf segment with input/output data. */ > > + uint32_t offset; > > + /**< The starting point for the Turbo input/output, in bytes, from th= e > > + * start of the data in the data buffer. It must be smaller than > > + * data_len of the mbuf's first segment! > > + */ > > + uint32_t length; > > + /**< For input operations: the length, in bytes, of the source buffer > > + * on which the Turbo encode/decode will be computed. > > + * For output operations: the length, in bytes, of the output buffer > > + * of the Turbo operation. > > + */ > > +}; >=20 > [...] > > +/** 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; > > + }; > > +}; >=20 > I am not sure it is a good idea to fit every operations in the same struc= t 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 th= e operation. >=20 > [...] > > +/** > > + * Helper macro for logging > > + * > > + * @param level > > + * Log level: EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, or > DEBUG > > + * @param fmt > > + * The format string, as in printf(3). > > + * @param ... > > + * The variable arguments required by the format string. > > + * > > + * @return > > + * - 0 on success > > + * - Negative on error > > + */ > > +#define rte_bbdev_log(level, fmt, ...) \ > > + RTE_LOG(level, BBDEV, fmt "\n", ##__VA_ARGS__) >=20 > This is the legacy log system. > Please use dynamic log type. Done. >=20 > [...] > > +#ifdef RTE_LIBRTE_BBDEV_DEBUG > > +#define rte_bbdev_log_verbose(fmt, ...) rte_bbdev_log_debug(fmt, > > +##__VA_ARGS__) #else #define rte_bbdev_log_verbose(fmt, ...) #endif >=20 > With the new log functions, you do not need to disable debug log at compi= lation > time. Right. >=20 > > +/** > > + * Initialisation params structure that can be used by software > > +based drivers */ struct rte_bbdev_init_params { > > + int socket_id; /**< Base band null device socket */ > > + uint16_t queues_num; /**< Base band null device queues number */ }; > > + > > +/** > > + * Parse generic parameters that could be used for software based devi= ces. > > + * > > + * @param params > > + * Pointer to structure that will hold the parsed parameters. > > + * @param input_args > > + * Pointer to arguments to be parsed. > > + * > > + * @return > > + * - 0 on success > > + * - EINVAL if invalid parameter pointer is provided > > + * - EFAULT if unable to parse provided arguments > > + */ > > +int > > +rte_bbdev_parse_params(struct rte_bbdev_init_params *params, > > + const char *input_args); >=20 > I do not understand the intent of these parameters. > Are they common to every PMDs? > Or could they be moved in software PMDs? That was an old design approach, but this now moved and became the responsibility of the soft PMD. >=20 > End of this first review pass :) Thanks!!