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 81BD8A2F18 for ; Thu, 3 Oct 2019 15:26:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2F2731C0CB; Thu, 3 Oct 2019 15:26:46 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 5BF911C0C8 for ; Thu, 3 Oct 2019 15:26:45 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 913F3B40076; Thu, 3 Oct 2019 13:26:43 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 3 Oct 2019 14:26:12 +0100 To: Ori Kam , Thomas Monjalon , Ferruh Yigit CC: "dev@dpdk.org" , "jingjing.wu@intel.com" , "stephen@networkplumber.org" References: <1569479349-36962-1-git-send-email-orika@mellanox.com> <1569479349-36962-2-git-send-email-orika@mellanox.com> <4c7da322-ea96-9649-b6cc-aad3a21df57a@solarflare.com> <87d7bb44-0537-3927-3276-e15743654268@solarflare.com> From: Andrew Rybchenko Message-ID: <02eda62f-f332-dbb4-240c-87c10b941ad0@solarflare.com> Date: Thu, 3 Oct 2019 16:26:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24950.003 X-TM-AS-Result: No-23.113500-8.000000-10 X-TMASE-MatchedRID: ZFzIhWOuIztjDV//SvkH3vZvT2zYoYOwC/ExpXrHizxi0lpUl7/AsTBk XchiUdrG/yYXddFq/9AwKp2rm/ymrGqLs+uf/K4tmvnKSb020hyhp756/rM6UrEe96bzLpOv/ns 36INbhdPt7QFjwl2OkyJ1igIe5xA1uuWkEgKXkGpStWLDoBpPUciZ5w9RXnqOIy9Gzx5fJCoo0E qA13zQc636FNpdXFk6tw1W8UQI+6tG7jIPw/RhECme9wbpQbK569xONVZSrH2ZfDRE1uqSgp2Py Nq+B8xIrxMUprgZXRq6KRwR1GrJ4WA2IAXETeuKcaD+wPaBYtZuQYcwHFo4BrjOUXWmQ3OWRiM0 r5DoZkA49xk3B+79kPU2ySga1ql0W8sQMvPj/Xxuh7qwx+D6T91hWsVVuzNoEcWQUCNHW2c/J5S KnlHdbS7AC099rWuYYiyvAp0VgvzMdO/aI0cjolH6kd/WWyJVq3wlNvsYBNhemWwoCXDj9YLQLU /wKQrFMcx2oVpjkHZsbFum7KynEVJN7bClZhykC7jPbMnguTDT2kl4i47LuyBnCaDsyOWno8WMk QWv6iWhMIDkR/KfwI2j49Ftap9EkGUtrowrXLg= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--23.113500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24950.003 X-MDID: 1570109204-Bg0J1waZDQCb Subject: Re: [dpdk-dev] [PATCH 01/13] ethdev: support setup function 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" Hi Ori, @Thomas, @Ferruh, please, see question below. On 10/2/19 3:19 PM, Ori Kam wrote: > Hi Andrew, > > Sorry it took me some time to responded, (I'm on vacation 😊) > I think we are in most cases in agreement. The only open issue is the > checks so please see my comments below. > As soon as we get to understanding about this issue, I will start working on V2. > > Thanks, > Ori [snip] >>>>>>> @@ -1769,6 +1793,60 @@ int rte_eth_rx_queue_setup(uint16_t port_id, >>>>>> uint16_t rx_queue_id, >>>>>>> struct rte_mempool *mb_pool); >>>>>>> >>>>>>> /** >>>>>>> + * @warning >>>>>>> + * @b EXPERIMENTAL: this API may change, or be removed, without prior >>>>>>> + notice >>>>>>> + * >>>>>>> + * Allocate and set up a hairpin receive queue for an Ethernet device. >>>>>>> + * >>>>>>> + * The function set up the selected queue to be used in hairpin. >>>>>>> + * >>>>>>> + * @param port_id >>>>>>> + * The port identifier of the Ethernet device. >>>>>>> + * @param rx_queue_id >>>>>>> + * The index of the receive queue to set up. >>>>>>> + * The value must be in the range [0, nb_rx_queue - 1] previously supplied >>>>>>> + * to rte_eth_dev_configure(). >>>>>> Is any Rx queue may be setup as hairpin queue? >>>>>> Can it be still used for regular traffic? >>>>>> >>>>> No if a queue is used as hairpin it can't be used for normal traffic. >>>>> This is also why I like the idea of two different functions, in order to create >>>>> This distinction. >>>> If so, do we need at least debug-level checks in Tx/Rx burst functions? >>>> Is it required to patch rte flow RSS action to ensure that Rx queues of >>>> only one kind are specified? >>>> What about attempt to add Rx/Tx callbacks for hairpin queues? >>>> >>> I think the checks should be done in PMD level. Since from high level they are the >>> same. >> Sorry, I don't understand why. If something could be checked on generic level, >> it should be done to avoid duplication in all drivers. > The issue with this approach is that at the ethdev level we don't know anything about the queue. > This will mean that we will need to add extra functions to query the queue type for each PMD. > We could also assume that if to get type function exist in the pmd then the queue is always standard queue. > So my suggestion if you would like to move the checks is to add queue type enum in the ethdev level, and add > function call to query the queue type. What do you think? I would consider to use dev_data rx_queue_state and tx_queue_state to keep the information to have it directly available without extra function calls. Or add extra information. dev_data is internal and it looks like not a problem. What do you think? >>> Call backs for Rx/Tx doesn't make sense, since the idea is to bypass the CPU. >> If so, I think rte_eth_add_tx_callback() should be patched to return an >> error >> if specified queue is hairpin. Same for Rx. >> Any other cases? >> > Same answer as above. [snip] Andrew.