Question about add ethdev loopback set API

Question about add ethdev loopback set API

[fengchengwen]

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.

Thanks

Re: Question about add ethdev loopback set API

[Ferruh Yigit]

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?

Re: Question about add ethdev loopback set API

[fengchengwen]

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.

> 
> 
> .
> 

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

Re: Question about add ethdev loopback set API

[fengchengwen]

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

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

Re: Question about add ethdev loopback set API

[fengchengwen]

On 2022/12/16 1:50, Ferruh Yigit wrote:
> 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().

Got it, I will send v1 later, thanks

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