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