From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id 8B7811BAAA for ; Thu, 26 Oct 2017 12:43:44 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id t139so7358580wmt.1 for ; Thu, 26 Oct 2017 03:43:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=wH4J1VexMfMy/X/bQJ1kO8gWZ7v3caAqBsXR1wcX5fQ=; b=Alhe0059+Cuz3pY2CxGW0CRE1UDUTg21PW0bP1XfvP08A8alvOF3/W+5r+QFmuzKOF ZrqW1wMS80R95QuThvlQBr0av7BbjIvI+XQUoZml0j/zgpdjPrsZLAdn/9vmfhgBglxB Wl6RbwiWn3KWYFljYbDZPGze/UDUrk4PesMoSiJw+4fvwuCdjZXOuDQTFsumTtp3PrXq Fp36QuoKW/VsDODkrgcbe6/z24Liq4/TtOnLLU5hYMNrEYqYoG33Zcc+kAkPySDz2C0v dpoD0LAUwKsT9vKOXzJRfhIO/UyIM8ReLTsIBK/i/sl7Z8ZxyBopMw08s7lONrXP0dMM 9t8g== X-Gm-Message-State: AMCzsaUwSZKWsFfKeJqHmM5WGTaPG9l9op74SKjBniNBJy8/5fj+iqny 9+01ZlTUG/dKVD2fNyiauVc= X-Google-Smtp-Source: ABhQp+S/pl+zk7VrawTmOZ3e0g4x2HylKvygP4H09eVxJxpWR5rjf5tL+nfQK8bZqfmRtvl8Ekmt/Q== X-Received: by 10.80.132.232 with SMTP id 95mr27458008edq.294.1509014623840; Thu, 26 Oct 2017 03:43:43 -0700 (PDT) Received: from localhost ([213.251.34.151]) by smtp.gmail.com with ESMTPSA id 3sm3310804edv.50.2017.10.26.03.43.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Oct 2017 03:43:43 -0700 (PDT) Message-ID: <1509014622.18107.2.camel@debian.org> From: Luca Boccassi To: "Dai, Wei" , "dev@dpdk.org" Cc: "Lu, Wenzhuo" , "Horton, Remy" Date: Thu, 26 Oct 2017 11:43:42 +0100 In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D650BA4316@PGSMSX106.gar.corp.intel.com> References: <20171024131630.16595-1-luca.boccassi@gmail.com> <49759EB36A64CF4892C1AFEC9231E8D650BA4316@PGSMSX106.gar.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 10:43:44 -0000 On Thu, 2017-10-26 at 08:08 +0000, Dai, Wei wrote: > 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. >=20 > It is the duty of user application to recovery any settings and > traffic by going through rte_eth_dev_configure(...),=C2=A0 > rte_eth_rx_queue_setup(...)/rte_eth_tx_queue_setup(...), > rte_eth_dev_start(...)=C2=A0 > and then rte_eth_rx_burst(...)/rte_eth_tx_burst(...). > In the recovery process,=C2=A0=C2=A0user application can use same or diff= erent > settings from those before reset. >=20 > Indeed, my patch use more generic way to reset NIC. > It has only been implemented on ixgbe VF and i40e VF currently. >=20 > You can test ixgbe VF reset with testpmd as follows: > 1.=C2=A0=C2=A0run testpmd with 2 ixgbe VF ports belonging to same PF in r= xonly > mode > 2.=C2=A0=C2=A0testpmd > set verbose 1 //to observe VF working=C2=A0 > 3.=C2=A0=C2=A0testpmd > show port info all //show port number and MAC add= r=C2=A0 > 4.=C2=A0=C2=A0testpmd > start=C2=A0 > 5.=C2=A0=C2=A0let all ports forwarding work for a while=C2=A0 > 6.=C2=A0=C2=A0testpmd > show port stats all=C2=A0 > 7.=C2=A0=C2=A0ifconfig name-of-PF down=C2=A0 > 8.=C2=A0=C2=A0A message is shown in testpmd to indicate PF reset=C2=A0 > 9.=C2=A0=C2=A0ifconfig name-of-PF up=C2=A0 > 10. testpmd > stop // stop forwarding to avoid crash during reset=C2=A0 > 11. testpmd > port stop all=C2=A0 > 12. testpmd > port reset all=C2=A0 > 13. testpmd > port start all //recofnig all ports {color}=C2=A0 > 14. testpmd > show port info all=C2=A0=C2=A0=C2=A0=C2=A0//get mapping of = port id and MAC > addr for forwarding=C2=A0 > 15. testpmd > start // restore forwarding=C2=A0 > 16. let all ports forwarding work for a while=C2=A0 > 17. testpmd > show port stats all //confirm all port can work again=C2=A0 > 18. repeat above step 7 - 17 >=20 > 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.=C2=A0 > 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. > =C2=A0 > Regards > -Wei Hi Wei, Thanks for having a look! So currently the documentation does not explicitly say that rte_eth- dev_configure/stop/start have to be called, but only to stop the queues, so it would be good to add it if that's the case. But on top of that, wouldn't it be better if the PMD handled that transparently? So that the application, as the documentation currently says, would only have to stop the queues, call reset and then restart them? Is there any particular reason why this can't be done like the RFC patches implement? > > -----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 ; Dai, Wei > >; > > Horton, Remy > > Subject: [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and > > ixgbe > >=20 > > From: Luca Boccassi > >=20 > > These patches were originally sent by Wenzhuo Lu: > >=20 > > http://dpdk.org/dev/patchwork/patch/14009/ > > http://dpdk.org/dev/patchwork/patch/14010/ > > http://dpdk.org/dev/patchwork/patch/14011/ > >=20 > > 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. > >=20 > > 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. > >=20 > > Thanks! > >=20 > > Luca Boccassi (3): > > =C2=A0 net/i40e: implement VF reset > > =C2=A0 net/e1000: implement VF reset > > =C2=A0 net/ixgbe: implement VF reset > >=20 > > =C2=A0drivers/net/e1000/igb_ethdev.c=C2=A0=C2=A0=C2=A0=C2=A0| 59 > > ++++++++++++++++++++++++++++++++++++++ > > =C2=A0drivers/net/i40e/i40e_ethdev.h=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2= =A03 ++ > > =C2=A0drivers/net/i40e/i40e_ethdev_vf.c | 56 > > +++++++++++++++++++++++++++++++++--- > > =C2=A0drivers/net/i40e/i40e_rxtx.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|= 11 +++++++ > > =C2=A0drivers/net/i40e/i40e_rxtx.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|= =C2=A0=C2=A04 +++ > > =C2=A0drivers/net/ixgbe/ixgbe_ethdev.c=C2=A0=C2=A0| 60 > > ++++++++++++++++++++++++++++++++++----- > > =C2=A0drivers/net/ixgbe/ixgbe_ethdev.h=C2=A0=C2=A0|=C2=A0=C2=A02 +- > > =C2=A0drivers/net/ixgbe/ixgbe_rxtx.c=C2=A0=C2=A0=C2=A0=C2=A0| 12 ++++++= -- > > =C2=A08 files changed, 192 insertions(+), 15 deletions(-) > >=20 > > -- > > 2.11.0 >=20 >=20 --=20 Kind regards, Luca Boccassi