From: "Dai, Wei" <wei.dai@intel.com>
To: "luca.boccassi@gmail.com" <luca.boccassi@gmail.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Horton, Remy" <remy.horton@intel.com>
Subject: Re: [dpdk-dev] [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe
Date: Thu, 26 Oct 2017 08:08:08 +0000 [thread overview]
Message-ID: <49759EB36A64CF4892C1AFEC9231E8D650BA4316@PGSMSX106.gar.corp.intel.com> (raw)
In-Reply-To: <20171024131630.16595-1-luca.boccassi@gmail.com>
Current rte_eth_dev_reset( ) from my patches are just to reset the NIC port, NOT recovery its traffic.
All my patches for NIC reset have already been accepted.
It is the duty of user application to recovery any settings and traffic by going through rte_eth_dev_configure(...),
rte_eth_rx_queue_setup(...)/rte_eth_tx_queue_setup(...), rte_eth_dev_start(...)
and then rte_eth_rx_burst(...)/rte_eth_tx_burst(...).
In the recovery process, user application can use same or different settings from those before reset.
Indeed, my patch use more generic way to reset NIC.
It has only been implemented on ixgbe VF and i40e VF currently.
You can test ixgbe VF reset with testpmd as follows:
1. run testpmd with 2 ixgbe VF ports belonging to same PF in rxonly mode
2. testpmd > set verbose 1 //to observe VF working
3. testpmd > show port info all //show port number and MAC addr
4. testpmd > start
5. let all ports forwarding work for a while
6. testpmd > show port stats all
7. ifconfig name-of-PF down
8. A message is shown in testpmd to indicate PF reset
9. ifconfig name-of-PF up
10. testpmd > stop // stop forwarding to avoid crash during reset
11. testpmd > port stop all
12. testpmd > port reset all
13. testpmd > port start all //recofnig all ports {color}
14. testpmd > show port info all //get mapping of port id and MAC addr for forwarding
15. testpmd > start // restore forwarding
16. let all ports forwarding work for a while
17. testpmd > show port stats all //confirm all port can work again
18. repeat above step 7 - 17
The codes to recover traffic using rte_eth_dev_reset(...) should like as follows:
1. rte_eth_dev_configure(...)
2. rte_eth_rx_queue_setup(...) + rte_eth_tx_queue_setup(...)
3. rte_eth_dev_callback_register(port_id, RTE_ETH_EVENT_INTR_RESET, eth_event_callback, cb_arg)
4. rte_eth_dev_start(...)
5. start transmitting and receiving
6. When detecting Reset event due to 'ifconfig PF down', eth_event_callback will be called.
eth_event_callback( ) should trigger following step 7-14
7. stop transmitting and receiving
8. wait and confirm both transmitting and receiving are stopped.
9. rte_eth_dev_stop(...)
10. try rte_eth_dev_reset(...) multiple times until it return 0, and then following step 11-14 to restart the port
11. rte_eth_dev_configure(...)
12. rte_eth_rx_queue_setup(...) + rte_eth_tx_queue_setup(...)
13. rte_eth_dev_start(...)
14. restart transmitting and receiving
All configurations including step 1/2/3/4/6/8/9/10/11/12/13 had better be run in same thread like testpmd main thread.
In above step 10, if the PF is down, rte_eth_dev_reset(...) will fail, so it should try multiple times until the PF is UP.
Regards
-Wei
> -----Original Message-----
> From: luca.boccassi@gmail.com [mailto:luca.boccassi@gmail.com]
> Sent: Tuesday, October 24, 2017 9:16 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Dai, Wei <wei.dai@intel.com>;
> Horton, Remy <remy.horton@intel.com>
> Subject: [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe
>
> From: Luca Boccassi <bluca@debian.org>
>
> These patches were originally sent by Wenzhuo Lu:
>
> http://dpdk.org/dev/patchwork/patch/14009/
> http://dpdk.org/dev/patchwork/patch/14010/
> http://dpdk.org/dev/patchwork/patch/14011/
>
> The current rte_eth_dev_reset API does not correctly reset the VF when the
> PF flaps on the host. With these patches, at least the ixgbe driver with a X540
> card (Linux kernel 4.9 on the host) appears to work correctly.
> The test is as simple ip link down/up on the host, and then check that traffic
> still flows through the VF in the guest.
>
> I am not an expert in these PMDs hence the RFC mark - I would like to ask for
> feedback and help from the PMD maintainers and developers.
>
> Thanks!
>
> Luca Boccassi (3):
> net/i40e: implement VF reset
> net/e1000: implement VF reset
> net/ixgbe: implement VF reset
>
> drivers/net/e1000/igb_ethdev.c | 59
> ++++++++++++++++++++++++++++++++++++++
> drivers/net/i40e/i40e_ethdev.h | 3 ++
> drivers/net/i40e/i40e_ethdev_vf.c | 56
> +++++++++++++++++++++++++++++++++---
> drivers/net/i40e/i40e_rxtx.c | 11 +++++++
> drivers/net/i40e/i40e_rxtx.h | 4 +++
> drivers/net/ixgbe/ixgbe_ethdev.c | 60
> ++++++++++++++++++++++++++++++++++-----
> drivers/net/ixgbe/ixgbe_ethdev.h | 2 +-
> drivers/net/ixgbe/ixgbe_rxtx.c | 12 ++++++--
> 8 files changed, 192 insertions(+), 15 deletions(-)
>
> --
> 2.11.0
next prev parent reply other threads:[~2017-10-26 8:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 13:16 luca.boccassi
2017-10-24 13:16 ` [dpdk-dev] [PATCH 1/3] net/i40e: implement VF reset luca.boccassi
2017-10-24 13:16 ` [dpdk-dev] [PATCH 2/3] net/e1000: " luca.boccassi
2017-10-24 13:16 ` [dpdk-dev] [PATCH 3/3] net/ixgbe: " luca.boccassi
2017-10-25 1:17 ` [dpdk-dev] [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe Ferruh Yigit
2017-10-25 10:04 ` Luca Boccassi
2017-10-26 8:08 ` Dai, Wei [this message]
2017-10-26 10:43 ` Luca Boccassi
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=49759EB36A64CF4892C1AFEC9231E8D650BA4316@PGSMSX106.gar.corp.intel.com \
--to=wei.dai@intel.com \
--cc=dev@dpdk.org \
--cc=luca.boccassi@gmail.com \
--cc=remy.horton@intel.com \
--cc=wenzhuo.lu@intel.com \
/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).