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(). >> >> >> >> 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. >> >> >> . >>
