Question about add ethdev loopback set API

[Ferruh Yigit]

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.