* Question about add ethdev loopback set API @ 2022-12-13 10:04 fengchengwen 2022-12-13 11:25 ` Ferruh Yigit 0 siblings, 1 reply; 7+ messages in thread From: fengchengwen @ 2022-12-13 10:04 UTC (permalink / raw) To: Ferruh Yigit, dev 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-13 10:04 Question about add ethdev loopback set API fengchengwen @ 2022-12-13 11:25 ` Ferruh Yigit 2022-12-14 7:25 ` fengchengwen 0 siblings, 1 reply; 7+ messages in thread From: Ferruh Yigit @ 2022-12-13 11:25 UTC (permalink / raw) To: fengchengwen; +Cc: dev 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-13 11:25 ` Ferruh Yigit @ 2022-12-14 7:25 ` fengchengwen 2022-12-14 10:38 ` Ferruh Yigit 0 siblings, 1 reply; 7+ messages in thread From: fengchengwen @ 2022-12-14 7:25 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev 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. > > > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-14 7:25 ` fengchengwen @ 2022-12-14 10:38 ` Ferruh Yigit 2022-12-15 12:46 ` fengchengwen 0 siblings, 1 reply; 7+ messages in thread From: Ferruh Yigit @ 2022-12-14 10:38 UTC (permalink / raw) To: fengchengwen; +Cc: dev, Andrew Rybchenko, Ori Kam, Thomas Monjalon 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-14 10:38 ` Ferruh Yigit @ 2022-12-15 12:46 ` fengchengwen 2022-12-15 17:50 ` Ferruh Yigit 0 siblings, 1 reply; 7+ messages in thread From: fengchengwen @ 2022-12-15 12:46 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Andrew Rybchenko, Ori Kam, Thomas Monjalon 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. > > > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-15 12:46 ` fengchengwen @ 2022-12-15 17:50 ` Ferruh Yigit 2022-12-16 1:07 ` fengchengwen 0 siblings, 1 reply; 7+ messages in thread From: Ferruh Yigit @ 2022-12-15 17:50 UTC (permalink / raw) To: fengchengwen; +Cc: dev, Andrew Rybchenko, Ori Kam, Thomas Monjalon 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. >> >> >> . >> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about add ethdev loopback set API 2022-12-15 17:50 ` Ferruh Yigit @ 2022-12-16 1:07 ` fengchengwen 0 siblings, 0 replies; 7+ messages in thread From: fengchengwen @ 2022-12-16 1:07 UTC (permalink / raw) To: Ferruh Yigit; +Cc: dev, Andrew Rybchenko, Ori Kam, Thomas Monjalon 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. >>> >>> >>> . >>> > > . > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-12-16 1:07 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-13 10:04 Question about add ethdev loopback set API 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 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).