From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CCE93A32A4 for ; Fri, 25 Oct 2019 16:09:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A8321C0D1; Fri, 25 Oct 2019 16:09:01 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id BB0CE1C0D0 for ; Fri, 25 Oct 2019 16:08:58 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2019 07:08:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,228,1569308400"; d="scan'208";a="373566654" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.10]) ([10.237.221.10]) by orsmga005.jf.intel.com with ESMTP; 25 Oct 2019 07:08:53 -0700 To: Thomas Monjalon , Haiyue Wang Cc: dev@dpdk.org, xiaolong.ye@intel.com, ray.kinsella@intel.com, bernard.iremonger@intel.com, chenmin.sun@intel.com, arybchenko@solarflare.com, viacheslavo@mellanox.com, stephen@networkplumber.org, david.marchand@redhat.com, jerinj@marvell.com References: <20191015075133.38560-1-haiyue.wang@intel.com> <20191015075133.38560-2-haiyue.wang@intel.com> <1682096.FjkMPolNrE@xps> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: <419163b4-2fe9-443c-0796-e928cdf697d6@intel.com> Date: Fri, 25 Oct 2019 15:08:52 +0100 MIME-Version: 1.0 In-Reply-To: <1682096.FjkMPolNrE@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/25/2019 10:36 AM, Thomas Monjalon wrote: > 15/10/2019 09:51, Haiyue Wang: >> Some PMDs have more than one RX/TX burst paths, add the ethdev API >> that allows an application to retrieve the mode information about >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology >> like AVX2. > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed. > Ferruh, I would expect to be Cc'ed and/or get a notification before merging. It has been discussed in the mail list and went through multiple discussions, patch is out since the August, +1 to cc all maintainers I missed that part, but when the patch is reviewed and there is no objection, why block the merge? > Hopefully it is not too late to fix this API before releasing 19.11. > > I think the idea of getting infos from PMD internal mode is not bad. > But I strongly disagree with standardizing the names. More below. > > [...] >> +enum rte_eth_burst_mode_option { >> + RTE_ETH_BURST_SCALAR = (1 << 0), >> + RTE_ETH_BURST_VECTOR = (1 << 1), > > 2 bits for a boolean value? > >> + >> + /**< bits[15:2] are reserved for each vector type */ >> + RTE_ETH_BURST_ALTIVEC = (1 << 2), >> + RTE_ETH_BURST_NEON = (1 << 3), >> + RTE_ETH_BURST_SSE = (1 << 4), >> + RTE_ETH_BURST_AVX2 = (1 << 5), >> + RTE_ETH_BURST_AVX512 = (1 << 6), >> + >> + RTE_ETH_BURST_SCATTERED = (1 << 16), /**< Support scattered packets */ >> + RTE_ETH_BURST_BULK_ALLOC = (1 << 17), /**< Support mbuf bulk alloc */ >> + RTE_ETH_BURST_SIMPLE = (1 << 18), > > What means simple? Looks meaningless. It is used in some drivers as simple scalar path with most features are missing. > >> + RTE_ETH_BURST_PER_QUEUE = (1 << 19), /**< Support per queue burst */ > > What is per-queue burst? No need to add a comment if not adding any info. > The burst API is *already* per-queue. That was a comment by me, most PMDs doesn't support different vector path per queue, for those PMDs, to make application life easy PMD can say if it supports per queue or not with this flag. If PMD supports only per port data path, application doesn't need to call this per queue if it want. > >> +}; > > How can we imagine standardizing the PMD optimizations? > PMD developers are free to have as many burst implementation as they want. > If we want to report info about what is used, it can be only a free string. The main target of the API is to define the vector path, not all optimizations, so the number is limited. When there is a standardized output it can be easier to be consumed by the applications. > >> +/** >> + * Ethernet device RX/TX queue packet burst mode information structure. >> + * Used to retrieve information about packet burst mode setting. >> + */ >> +struct rte_eth_burst_mode { >> + uint64_t options; >> +}; > > Why a struct for an integer? Again by a request from me, to not need to break the API if we need to add more thing in the future. > >> +/** >> + * Retrieve information about the Rx packet burst mode. >> + * >> + * @param port_id >> + * The port identifier of the Ethernet device. >> + * @param queue_id >> + * The Rx queue on the Ethernet device for which information >> + * will be retrieved. >> + * @param mode >> + * A pointer to a structure of type *rte_eth_burst_mode* to be filled >> + * with the information of the packet burst mode. > > No reference to the enum rte_eth_burst_mode_option or RTE_ETH_BURST_ prefix? > >> + * >> + * @return >> + * - 0: Success >> + * - -ENOTSUP: routine is not supported by the device PMD. >> + * - -EINVAL: The port_id or the queue_id is out of range. >> + */ >> +__rte_experimental >> +int rte_eth_rx_burst_mode_get(uint16_t port_id, uint16_t queue_id, >> + struct rte_eth_burst_mode *mode); > [...] >> +/** >> + * Retrieve name about burst mode option. >> + * >> + * @param mode >> + * The burst mode option of type *rte_eth_burst_mode_option*. >> + * >> + * @return >> + * - "": Not found >> + * - "xxx": name of the mode option. >> + */ >> +__rte_experimental >> +const char * >> +rte_eth_burst_mode_option_name(uint64_t option); > > rte_eth_burst_mode_name would be a better function name. > But anyway, this function should not exist. > The string should be freely returned by the PMD > in the burst_mode_get functions.