Question about add ethdev loopback set API

[Ferruh Yigit]

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