From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DA37BA0543; Fri, 16 Dec 2022 02:07:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7C27140695; Fri, 16 Dec 2022 02:07:54 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id D4F3B40685 for ; Fri, 16 Dec 2022 02:07:52 +0100 (CET) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4NY9py2VDxzJpPk; Fri, 16 Dec 2022 09:04:10 +0800 (CST) Received: from [10.67.100.224] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Fri, 16 Dec 2022 09:07:50 +0800 Subject: Re: Question about add ethdev loopback set API To: Ferruh Yigit CC: "dev@dpdk.org" , Andrew Rybchenko , Ori Kam , Thomas Monjalon References: <1109431c-2b18-cc02-5e36-5c1e2d298a82@amd.com> <2d70ef33-5cc8-f56e-91c1-a44fd5450ba2@huawei.com> <3fa49fba-4eaf-afd4-7677-9a50713eca04@huawei.com> <9347efde-b15f-a611-affd-a486a47bb44c@amd.com> From: fengchengwen Message-ID: <05ff0ea0-1ff4-b305-bd1a-e32dda78b4c7@huawei.com> Date: Fri, 16 Dec 2022 09:07:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <9347efde-b15f-a611-affd-a486a47bb44c@amd.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2022/12/16 1:50, Ferruh Yigit wrote: > On 12/15/2022 12:46 PM, fengchengwen wrote: >> On 2022/12/14 18:38, Ferruh Yigit wrote: >>> On 12/14/2022 7:25 AM, fengchengwen wrote: >>>> On 2022/12/13 19:25, Ferruh Yigit wrote: >>>>> On 12/13/2022 10:04 AM, fengchengwen wrote: >>>>>> Hi Ferruh, >>>>>> >>>>>> During the test, we need to delineate where go wrong when encountered >>>>>> e.g. CRC error. In this scenario, loopback is useful. >>>>>> >>>>>> I think we can add a loopback set API which could set inner or outer loop, >>>>>> and user can use telemetry to set the loopback in the above scenario. >>>>>> >>>>>> I'd like to hear your opinion about add a loopback set API. >>>>>> >>>>> >>>>> Hi Chengwen, >>>>> >>>>> Is the intention to test ethdev layer or driver? >>>>> >>>>> It is possible to use ring vdev to create a loopback and to test ethdev >>>>> layer. >>>>> >>>>> For driver, it can be possible to create physical loopback connection, >>>>> or even can implement loopback Rx/Tx burst functions in driver. >>>>> Using another host to send/receive packets to DUT (device under test) is >>>>> another approach. >>>>> >>>>> >>>>> What kind of loopback implementation do you have in your mind? >>>> >>>> Mainly MAC layer and lower physical layer: >>>> >>>> -------- --------------- ------------ ---------- -------------------- >>>> | | | - rx | | - rx - | | - rx - | | | >>>> | Host | - | MAC | - | SerDes | - | PHY | ==== | Packet Generator | >>>> | | | - tx | | - tx - | | - tx - | | | >>>> -------- --------------- ------------ ---------- -------------------- >>>> >>>> The support loopback in hns3 platform: >>>> Inner loopback subtypes: which host send pkts and recv and then verify: >>>> Serdes tx to rx >>>> PHY tx to rx >>>> >>>> Outer loopback subtypes: which Packet-Generator send pkts and recv and then verify: >>>> MAC tx to rx >>>> >>>> I think we could support the above loopback types, and maybe other PMD platform support >>>> more loopback types. >>>> >>> >>> There is a 'lpbk_mode' field of "struct rte_eth_conf", to configure >>> loopback in 'rte_eth_dev_configure()', >>> but it isn't fine grained to define the possible modes you mentioned >>> above. Currently '0' means loopback disabled and non zero means it is >>> enabled, details left to drivers. >>> >>> 'lpbk_mode' is 32bit, we have space to define detailed loopback modes. >> >> Emm, I found the lpbk_mode is not defined in a unified manner, which is vendor specified. >> >>> >>> >>> Having loopback configuration in 'rte_eth_dev_configure()' requires port >>> to stop and reconfigure to enable/disable loopback. >>> If it is possible to change loopback behavior without full >>> reconfiguration cycle, we can add two new APIs to enable/disable >>> loopback. But this has the downside of two different APIs change same >>> config, and we had problems related this in the past. >> >> Yes, the 'use rte_eth_dev_configure() to config loopback' is inflexible, and I also notice >> the testpmd command "set tx loopback port-id on/off", and it invoke PMD's public API which >> is rte_pmd_ixgbe/i40e/bnxt/dpaa_set_tx_loopback. According to this information, loopback >> needs to be configured during running. >> >> So I suggest add one API: >> >> int rte_eth_dev_set_loopback(uint16_t port_id, uint32_t lpbk_mode), and costraint >> this API can only invoke when port is started, if turn off (lpbk_mode==0) then should >> recovering rte_eth_conf's lpbk_mode. >> >> Also the lpbk_mode is vendor specified. >> > > 'lpbk_mode' is 32bit, we can define as some X bits still will be used as > vendor specific manner, but rest is defined. I think this can work. > > OK to have new API, and use 'lpbk_mode' parameter of it exactly as it is > used by rte_eth_dev_configure(). Got it, I will send v1 later, thanks > > >>> >>> >>> >>> Also there is a hairpin feature in ethdev, that connects Rx queue back >>> to Tx queue, but not sure if that justifies your "MAC tx ro rx" testcase. >>> >>> >>> . >>> > > . >