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 7BCE4A0353; Tue, 5 Nov 2019 13:23:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4F18934F3; Tue, 5 Nov 2019 13:23:27 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 715052C15 for ; Tue, 5 Nov 2019 13:23:25 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2019 04:23:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,271,1569308400"; d="scan'208";a="204961305" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.96]) ([10.237.221.96]) by orsmga003.jf.intel.com with ESMTP; 05 Nov 2019 04:23:21 -0800 To: Andrew Rybchenko , Ori Kam , John McNamara , Marko Kovacevic , Thomas Monjalon Cc: "dev@dpdk.org" , "jingjing.wu@intel.com" , "stephen@networkplumber.org" , Jerin Jacob References: <1569479349-36962-1-git-send-email-orika@mellanox.com> <1572479604-178752-1-git-send-email-orika@mellanox.com> <1572479604-178752-3-git-send-email-orika@mellanox.com> <10616bdb-4314-833e-d05e-ab5674763ae1@intel.com> <676258d8-83e6-754c-681e-1e60099f4b31@solarflare.com> <4ec1b7f2-9896-b1e5-8a11-177b7b14eaac@intel.com> <38e339da-9900-0e7e-2686-385d77023575@solarflare.com> 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: <14821917-596c-06b9-e5db-eaa1c1c8ffbe@intel.com> Date: Tue, 5 Nov 2019 12:23:21 +0000 MIME-Version: 1.0 In-Reply-To: <38e339da-9900-0e7e-2686-385d77023575@solarflare.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v7 02/14] ethdev: add support for hairpin queue 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 11/5/2019 12:12 PM, Andrew Rybchenko wrote: > On 11/5/19 3:05 PM, Ferruh Yigit wrote: >> On 11/5/2019 11:49 AM, Andrew Rybchenko wrote: >>> On 11/5/19 2:36 PM, Ori Kam wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ferruh Yigit >>>>> Sent: Tuesday, November 5, 2019 1:25 PM >>>>> To: Ori Kam ; John McNamara >>>>> ; Marko Kovacevic >>>>> ; Thomas Monjalon ; >>>>> Andrew Rybchenko >>>>> Cc: dev@dpdk.org; jingjing.wu@intel.com; stephen@networkplumber.org; Jerin >>>>> Jacob >>>>> Subject: Re: [PATCH v7 02/14] ethdev: add support for hairpin queue >>>>> >>>>> On 10/30/2019 11:53 PM, Ori Kam wrote: >>>>>> This commit introduce hairpin queue type. >>>>>> >>>>>> The hairpin queue in build from Rx queue binded to Tx queue. >>>>>> It is used to offload traffic coming from the wire and redirect it back >>>>>> to the wire. >>>>>> >>>>>> There are 3 new functions: >>>>>> - rte_eth_dev_hairpin_capability_get >>>>>> - rte_eth_rx_hairpin_queue_setup >>>>>> - rte_eth_tx_hairpin_queue_setup >>>>>> >>>>>> In order to use the queue, there is a need to create rte_flow >>>>>> with queue / RSS action that targets one or more of the Rx queues. >>>>>> >>>>>> Signed-off-by: Ori Kam >>>>>> Reviewed-by: Andrew Rybchenko >>>>> >>>>> <...> >>>>> >>>>>> #include >>>>>> >>>>>> /** >>>>>> + * @internal >>>>>> + * Check if the selected Rx queue is hairpin queue. >>>>>> + * >>>>>> + * @param dev >>>>>> + * Pointer to the selected device. >>>>>> + * @param queue_id >>>>>> + * The selected queue. >>>>>> + * >>>>>> + * @return >>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise. >>>>>> + */ >>>>>> +int >>>>>> +rte_eth_dev_is_rx_hairpin_queue(struct rte_eth_dev *dev, uint16_t >>>>> queue_id); >>>>>> + >>>>>> +/** >>>>>> + * @internal >>>>>> + * Check if the selected Tx queue is hairpin queue. >>>>>> + * >>>>>> + * @param dev >>>>>> + * Pointer to the selected device. >>>>>> + * @param queue_id >>>>>> + * The selected queue. >>>>>> + * >>>>>> + * @return >>>>>> + * - (1) if the queue is hairpin queue, 0 otherwise. >>>>>> + */ >>>>>> +int >>>>>> +rte_eth_dev_is_tx_hairpin_queue(struct rte_eth_dev *dev, uint16_t >>>>> queue_id); >>>>>> + >>>>>> +/** >>>>> >>>>> If these functions are internal why there are in 'rte_ethdev.h' ? >>>>> >>>>>> * >>>>>> * Retrieve a burst of input packets from a receive queue of an Ethernet >>>>>> * device. The retrieved packets are stored in *rte_mbuf* structures whose >>>>>> @@ -4251,6 +4400,11 @@ int rte_eth_dev_adjust_nb_rx_tx_desc(uint16_t >>>>> port_id, >>>>>> RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", >>>>> queue_id); >>>>>> return 0; >>>>>> } >>>>>> + if (rte_eth_dev_is_rx_hairpin_queue(dev, queue_id)) { >>>>>> + RTE_ETHDEV_LOG(ERR, "Rx burst failed, queue_id=%u is >>>>> hairpin queue\n", >>>>>> + queue_id); >>>>>> + return 0; >>>>>> + } >>>>>> #endif >>>>>> nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], >>>>>> rx_pkts, nb_pkts); >>>>>> @@ -4517,6 +4671,11 @@ static inline int >>>>> rte_eth_tx_descriptor_status(uint16_t port_id, >>>>>> RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", >>>>> queue_id); >>>>>> return 0; >>>>>> } >>>>>> + if (rte_eth_dev_is_tx_hairpin_queue(dev, queue_id)) { >>>>>> + RTE_ETHDEV_LOG(ERR, "Tx burst failed, queue_id=%u is >>>>> hairpin queue\n", >>>>>> + queue_id); >>>>>> + return 0; >>>>>> + } >>>>>> #endif >>>>> >>>>> Hi Ori, >>>>> >>>>> These are causing build error, thanks Jerin for catching, because they are >>>>> internal and called by a public static inline API, so whoever calls >>>>> 'rte_eth_rx/tx_burst()' APIs in the shared build, can't find >>>>> 'rte_eth_dev_is_rx/tx_hairpin_queue()' functions [1], >>>>> >>>>> as far as I can see there are two options: >>>>> 1) Remove these checks >>>>> 2) Make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API instead of internal >>>>> >>>>> If there is a value to make 'rte_eth_dev_is_rx/tx_hairpin_queue()' public API >>>>> we >>>>> should go with (2) else (1). >>>>> >>>> >>>> I think we can skip the tests, >>>> But it was Andrew request so we must get is response. >>>> It was also his empathies that they should be internal. >>> >>> It is important for me to keep rte_eth_dev_state internal and >>> few patches ago rte_eth_dev_is_rx_hairpin_queue() was inline. >> >> Are you saying you don't want to option to make >> 'rte_eth_dev_is_rx_hairpin_queue()' static inline because it will force the >> 'RTE_ETH_QUEUE_STATE_xxx' being public? > > Yes. +1 > >>> I'm OK to make the function experimental or keep it internal >>> (no API/ABI stability requirements) but externally visible (in .map). >> >> I think we can't do this, add a function deceleration to the public header file >> and add it to the .map file but keep it internal. Instead we can make it a >> proper API and it should be experimental at least first release. > > We have discussed similar thing with Olivier recently [1]. > > [1] http://inbox.dpdk.org/dev/20191030142938.bpi4txlrebqfq7uw@platinum/ Yes we can say they are internal but there won't be anything preventing applications to use them. > >> The question above was do we need this API, or instead should remove the check >> from rx/tx_burst APIs? > > I think these checks are useful to ensure that these functions > are not used for hairpin queues. At least to catch it with debug > enabled. OK, if so what not make them proper API? Any concern on it? > >>>>> [1] >>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_eth_rx': >>>>> rte_event_eth_rx_adapter.c:(.text+0x1728): undefined reference to >>>>> `rte_eth_dev_is_rx_hairpin_queue' >>>>> /usr/bin/ld: rte_event_eth_rx_adapter.o: in function `rxa_service_func': >>>>> rte_event_eth_rx_adapter.c:(.text+0x22ab): undefined reference to >>>>> `rte_eth_dev_is_rx_hairpin_queue' >>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_buffer_retry': >>>>> rte_event_eth_tx_adapter.c:(.text+0xa43): undefined reference to >>>>> `rte_eth_dev_is_tx_hairpin_queue' >>>>> /usr/bin/ld: rte_event_eth_tx_adapter.o: in function `txa_service_func': >>>>> rte_event_eth_tx_adapter.c:(.text+0xe7d): undefined reference to >>>>> `rte_eth_dev_is_tx_hairpin_queue' >>>>> /usr/bin/ld: rte_event_eth_tx_adapter.c:(.text+0x1155): undefined reference to >>>>> `rte_eth_dev_is_tx_hairpin_queue' >>>>> collect2: error: ld returned 1 exit status >>> >