From: fengchengwen <fengchengwen@huawei.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Ori Kam <orika@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>
Subject: Re: Question about add ethdev loopback set API
Date: Fri, 16 Dec 2022 09:07:49 +0800 [thread overview]
Message-ID: <05ff0ea0-1ff4-b305-bd1a-e32dda78b4c7@huawei.com> (raw)
In-Reply-To: <9347efde-b15f-a611-affd-a486a47bb44c@amd.com>
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.
>>>
>>>
>>> .
>>>
>
> .
>
prev parent reply other threads:[~2022-12-16 1:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 10:04 fengchengwen
2022-12-13 11:25 ` Ferruh Yigit
2022-12-14 7:25 ` fengchengwen
2022-12-14 10:38 ` Ferruh Yigit
2022-12-15 12:46 ` fengchengwen
2022-12-15 17:50 ` Ferruh Yigit
2022-12-16 1:07 ` fengchengwen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05ff0ea0-1ff4-b305-bd1a-e32dda78b4c7@huawei.com \
--to=fengchengwen@huawei.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).