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