From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Chen, Jing D" <jing.d.chen@intel.com>,
"Liang, Cunming" <cunming.liang@intel.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset
Date: Wed, 22 Jun 2016 13:29:32 +0530 [thread overview]
Message-ID: <20160622075930.GA2577@localhost.localdomain> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09090348987B@shsmsx102.ccr.corp.intel.com>
On Wed, Jun 22, 2016 at 06:42:43AM +0000, Lu, Wenzhuo wrote:
> Hi Jerin,
>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Wednesday, June 22, 2016 2:10 PM
> > To: Lu, Wenzhuo
> > Cc: Ananyev, Konstantin; Stephen Hemminger; dev@dpdk.org; Richardson,
> > Bruce; Chen, Jing D; Liang, Cunming; Wu, Jingjing; Zhang, Helin;
> > thomas.monjalon@6wind.com
> > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset
> >
> > On Wed, Jun 22, 2016 at 05:05:14AM +0000, Lu, Wenzhuo wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > > Sent: Wednesday, June 22, 2016 12:15 PM
> > > > To: Lu, Wenzhuo
> > > > Cc: Ananyev, Konstantin; Stephen Hemminger; dev@dpdk.org;
> > > > Richardson, Bruce; Chen, Jing D; Liang, Cunming; Wu, Jingjing;
> > > > Zhang, Helin; thomas.monjalon@6wind.com
> > > > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support
> > > > device reset
> > > >
> > > > On Wed, Jun 22, 2016 at 03:32:16AM +0000, Lu, Wenzhuo wrote:
> > > > > Lost here. I think these RTE_ETH_EVENTs are used to connect the
> > > > > APP call
> > > > back functions with the events.
> > > > > Actually I want the APP to register a callback function
> > > > > reset_event_callback for
> > > > the reset event. Like this,
> > > > > /* register reset interrupt callback */
> > > > > rte_eth_dev_callback_register(portid,
> > > > > RTE_ETH_EVENT_INTR_RESET, reset_event_callback,
> > > > NULL); And when the
> > > > > VF driver finds PF link down/up, it should use
> > > > _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET) to run
> > > > into the callback which is provided by APP. Means reset_event_callback here.
> > > >
> > > > me too. Their is existing RTE_ETH_EVENT_INTR_RESET event to notify
> > > > the PF reset.I guess it is not for the PF link change or it isfor
> > > > generic VF reset request initiated by PF for everything.
> > > I think this event is for device reset not only for PF but also can for VF. I think
> > we can use this event when the driver want the APP to reset the device. The PF
> > link down/up caused VF reset is one of the cases.
> >
> > Then please correct description for the RTE_ETH_EVENT_INTR_RESET in
> > lib/librte_ether/rte_ethdev.h "/**< reset interrupt event, sent to VF on PF reset
> > */"
> >
> > >
> > > >
> > > > file: lib/librte_ether/rte_ethdev.h
> > > > RTE_ETH_EVENT_INTR_RESET,
> > > > /**< reset interrupt event, sent to VF on PF reset */
> > > >
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > >
> > > > if application need to call rte_ethdev_reset() on
> > > > RTE_ETH_EVENT_INTR_RESET event then please mention it commit log or
> > API description.
> > > Good suggestion. I'll try to find where's the good place to add more
> > explanation.
> >
> > I guess then reset API can be changed to rte_ethdev_process_reset_intr() or
> > similar to reflect the use case(API called by application on reset event from PF)
> >
> > The PMDs were PF does not generate the RTE_ETH_EVENT_INTR_RESET to VF
> > then VF's reset PMD callback shall be a 'nop'
> >
> > Jerin
> But I don't think it's appropriate to bind the RTE_ETH_EVENTs with the APIs. This patch set provide a reset API to reset the device. Don't mean this reset API only can be used when the APP hit the event RTE_ETH_EVENT_INTR_RESET. I can add some comments to suggest the user to call the reset API at that time. But I think APP can call the reset API anytime when it thinks it's necessary. So I don't like the name *process_reset_intr*, it hints that this API is only for the INTR_RESET event.
That's where scope of API and PMD implementation its not getting clear.
Can you tell me any other use case where we need to call this API from application.
The name rte_ethdev_reset() is too generic. If you are going with that
generic name then you may need add lot of details in API description.
Thomas,
As a librte_ether maintainer any comments on this?
>
> >
> > > >
> > >
next prev parent reply other threads:[~2016-06-22 7:59 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 5:40 [dpdk-dev] [PATCH 0/8] support reset of VF link Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 1/8] lib/librte_ether: support device reset Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock mode Wenzhuo Lu
2016-06-08 2:15 ` Stephen Hemminger
2016-06-08 7:34 ` Lu, Wenzhuo
2016-06-09 7:50 ` Olivier Matz
2016-06-12 5:25 ` Lu, Wenzhuo
2016-06-10 18:12 ` Stephen Hemminger
2016-06-12 5:27 ` Lu, Wenzhuo
2016-06-06 5:40 ` [dpdk-dev] [PATCH 3/8] ixgbe: RX/TX with lock on VF Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 4/8] ixgbe: implement device reset " Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 5/8] igb: RX/TX with lock " Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 6/8] igb: implement device reset " Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 7/8] i40e:RX/TX with lock " Wenzhuo Lu
2016-06-06 5:40 ` [dpdk-dev] [PATCH 8/8] i40e: implement device reset " Wenzhuo Lu
2016-06-15 3:03 ` [dpdk-dev] [PATCH v5 0/4] support reset of VF link Wenzhuo Lu
2016-06-15 3:03 ` [dpdk-dev] [PATCH v5 1/4] lib/librte_ether: support device reset Wenzhuo Lu
2016-06-16 15:31 ` Bruce Richardson
2016-06-16 15:36 ` Thomas Monjalon
2016-06-15 3:03 ` [dpdk-dev] [PATCH v5 2/4] ixgbe: implement device reset on VF Wenzhuo Lu
2016-06-15 3:03 ` [dpdk-dev] [PATCH v5 3/4] igb: " Wenzhuo Lu
2016-06-15 3:03 ` [dpdk-dev] [PATCH v5 4/4] i40e: " Wenzhuo Lu
2016-06-20 6:24 ` [dpdk-dev] [PATCH v6 0/4] support reset of VF link Wenzhuo Lu
2016-06-20 6:24 ` [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset Wenzhuo Lu
2016-06-20 9:14 ` Jerin Jacob
2016-06-20 16:17 ` Stephen Hemminger
2016-06-21 3:51 ` Jerin Jacob
2016-06-21 6:14 ` Lu, Wenzhuo
2016-06-21 7:37 ` Jerin Jacob
2016-06-21 8:24 ` Lu, Wenzhuo
2016-06-21 8:55 ` Jerin Jacob
2016-06-21 9:26 ` Ananyev, Konstantin
2016-06-21 10:57 ` Jerin Jacob
2016-06-21 13:10 ` Ananyev, Konstantin
2016-06-21 13:30 ` Jerin Jacob
2016-06-21 14:03 ` Ananyev, Konstantin
2016-06-21 14:29 ` Jerin Jacob
2016-06-22 1:35 ` Lu, Wenzhuo
2016-06-22 2:37 ` Jerin Jacob
2016-06-22 3:32 ` Lu, Wenzhuo
2016-06-22 4:14 ` Jerin Jacob
2016-06-22 5:05 ` Lu, Wenzhuo
2016-06-22 6:10 ` Jerin Jacob
2016-06-22 6:42 ` Lu, Wenzhuo
2016-06-22 7:59 ` Jerin Jacob [this message]
2016-06-22 8:17 ` Thomas Monjalon
2016-06-22 8:25 ` Lu, Wenzhuo
2016-06-22 9:18 ` Thomas Monjalon
2016-06-22 11:06 ` Jerin Jacob
2016-06-23 0:45 ` Lu, Wenzhuo
2016-06-23 0:39 ` Lu, Wenzhuo
2016-06-21 0:51 ` Lu, Wenzhuo
2016-06-20 6:24 ` [dpdk-dev] [PATCH v6 2/4] ixgbe: implement device reset on VF Wenzhuo Lu
2016-06-20 6:24 ` [dpdk-dev] [PATCH v6 3/4] igb: " Wenzhuo Lu
2016-06-20 6:24 ` [dpdk-dev] [PATCH v6 4/4] i40e: " Wenzhuo Lu
2016-07-04 15:48 ` [dpdk-dev] [PATCH v6 0/4] support reset of VF link Luca Boccassi
2016-07-05 0:52 ` Lu, Wenzhuo
2016-07-05 9:52 ` Luca Boccassi
2016-07-06 0:45 ` Lu, Wenzhuo
2016-07-06 16:26 ` Luca Boccassi
[not found] ` <1467822182.32466.34.camel@brocade.com>
2016-07-07 1:09 ` Lu, Wenzhuo
2016-07-07 10:20 ` Luca Boccassi
2016-07-07 13:12 ` Lu, Wenzhuo
2016-07-07 16:19 ` Luca Boccassi
2016-07-08 0:14 ` Lu, Wenzhuo
2016-07-08 17:15 ` Luca Boccassi
2016-07-11 1:32 ` Lu, Wenzhuo
2016-07-11 12:02 ` Luca Boccassi
2016-07-11 15:43 ` Luca Boccassi
2016-07-12 1:19 ` Lu, Wenzhuo
2016-08-26 12:58 ` Luca Boccassi
2016-08-29 1:04 ` Lu, Wenzhuo
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=20160622075930.GA2577@localhost.localdomain \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=cunming.liang@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jing.d.chen@intel.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.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).