Message ID | 1472202620-20487-2-git-send-email-bernard.iremonger@intel.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Thomas Monjalon |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 9DC285901; Fri, 26 Aug 2016 11:10:29 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2245058EC for <dev@dpdk.org>; Fri, 26 Aug 2016 11:10:27 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 26 Aug 2016 02:10:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.28,580,1464678000"; d="scan'208"; a="1031602808" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga001.fm.intel.com with ESMTP; 26 Aug 2016 02:10:25 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id u7Q9AO2w018161; Fri, 26 Aug 2016 10:10:24 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id u7Q9AOwa020535; Fri, 26 Aug 2016 10:10:24 +0100 Received: (from bairemon@localhost) by sivswdev01.ir.intel.com with id u7Q9AOM7020530; Fri, 26 Aug 2016 10:10:24 +0100 From: Bernard Iremonger <bernard.iremonger@intel.com> To: rahul.r.shah@intel.com, wenzhuo.lu@intel.com, dev@dpdk.org Cc: Bernard Iremonger <bernard.iremonger@intel.com>, azelezniak <alexz@att.com> Date: Fri, 26 Aug 2016 10:10:16 +0100 Message-Id: <1472202620-20487-2-git-send-email-bernard.iremonger@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1472202620-20487-1-git-send-email-bernard.iremonger@intel.com> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1472202620-20487-1-git-send-email-bernard.iremonger@intel.com> Subject: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Iremonger, Bernard
Aug. 26, 2016, 9:10 a.m. UTC
add _rte_eth_dev_callback_process_vf function. add _rte_eth_dev_callback_process_generic function Adding a callback to the user application on VF to PF mailbox message, allows passing information to the application controlling the PF when a VF mailbox event message is received, such as VF reset. Signed-off-by: azelezniak <alexz@att.com> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> --- lib/librte_ether/rte_ethdev.c | 17 ++++++++++ lib/librte_ether/rte_ethdev.h | 61 ++++++++++++++++++++++++++++++++++ lib/librte_ether/rte_ether_version.map | 7 ++++ 3 files changed, 85 insertions(+)
Comments
On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > add _rte_eth_dev_callback_process_vf function. > add _rte_eth_dev_callback_process_generic function > > Adding a callback to the user application on VF to PF mailbox message, > allows passing information to the application controlling the PF > when a VF mailbox event message is received, such as VF reset. > > Signed-off-by: azelezniak <alexz@att.com> > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > --- > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > lib/librte_ether/rte_ethdev.h | 61 ++++++++++++++++++++++++++++++++++ > lib/librte_ether/rte_ether_version.map | 7 ++++ > 3 files changed, 85 insertions(+) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index f62a9ec..1388ea3 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -2690,6 +2690,20 @@ void > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > enum rte_eth_event_type event) > { > + return _rte_eth_dev_callback_process_generic(dev, event, NULL); > +} > + > +void > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > + enum rte_eth_event_type event, void *param) > +{ > + return _rte_eth_dev_callback_process_generic(dev, event, param); > +} > + > +void > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, > + enum rte_eth_event_type event, void *param) > +{ > struct rte_eth_dev_callback *cb_lst; > struct rte_eth_dev_callback dev_cb; > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > continue; > dev_cb = *cb_lst; > cb_lst->active = 1; > + if (param != NULL) > + dev_cb.cb_arg = (void *) param; > + > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > dev_cb.cb_arg); > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > index b0fe033..4fb0b9c 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > /**< queue state event (enabled/disabled) */ > RTE_ETH_EVENT_INTR_RESET, > /**< reset interrupt event, sent to VF on PF reset */ > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > RTE_ETH_EVENT_MAX /**< max value of this enum */ > }; > > +/** > + * Response sent back to ixgbe driver from user app after callback > + */ > +enum rte_eth_mb_event_rsp { > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK */ > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and NACK */ > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request */ > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ > +}; Do we really need to define the specifics of PF to VF MBOX communication in normative ethdev specification? Each drivers may have different PF to VF MBOX definitions so it may not be very portable. What is the use-case here? If its for VF configuration, I think we can do it as separate 'sync' functions for each functionality so that PMDs will have room hiding the specifics on MBOX definitions.
On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > Use case could be to inform application managing SRIOV about VM's intention > to modify parameters like add VLAN which might not be the one which is > assigned to VF or inform about VF reset and reapply settings like strip/insert > VLAN id based on policy. Is there any other way(more portable way) where we can realize the same use case? Something like, 1) The assigned VM operates/control the VF 2) A centralized entity post messages through UNIX socket or something(like vhost user communicates with VM). On message receive, VM can take necessary action on assigned VF. This will avoid the need of defining specifics of PF to VF mailbox communication in normative ethdev specification. And I guess it will work almost the PMD drivers as their is no PMD specific work here. Just a thought. > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Friday, September 09, 2016 10:11 AM > > To: Bernard Iremonger <bernard.iremonger@intel.com> > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > ZELEZNIAK, ALEX <az5157@att.com> > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > callback functions > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > add _rte_eth_dev_callback_process_vf function. > > > add _rte_eth_dev_callback_process_generic function > > > > > > Adding a callback to the user application on VF to PF mailbox message, > > > allows passing information to the application controlling the PF > > > when a VF mailbox event message is received, such as VF reset. > > > > > > Signed-off-by: azelezniak <alexz@att.com> > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > --- > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > lib/librte_ether/rte_ethdev.h | 61 > > ++++++++++++++++++++++++++++++++++ > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > 3 files changed, 85 insertions(+) > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > > > index f62a9ec..1388ea3 100644 > > > --- a/lib/librte_ether/rte_ethdev.c > > > +++ b/lib/librte_ether/rte_ethdev.c > > > @@ -2690,6 +2690,20 @@ void > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > enum rte_eth_event_type event) > > > { > > > + return _rte_eth_dev_callback_process_generic(dev, event, NULL); > > > +} > > > + > > > +void > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > + enum rte_eth_event_type event, void *param) > > > +{ > > > + return _rte_eth_dev_callback_process_generic(dev, event, param); > > > +} > > > + > > > +void > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, > > > + enum rte_eth_event_type event, void *param) > > > +{ > > > struct rte_eth_dev_callback *cb_lst; > > > struct rte_eth_dev_callback dev_cb; > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > rte_eth_dev *dev, > > > continue; > > > dev_cb = *cb_lst; > > > cb_lst->active = 1; > > > + if (param != NULL) > > > + dev_cb.cb_arg = (void *) param; > > > + > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > dev_cb.cb_arg); > > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > > > index b0fe033..4fb0b9c 100644 > > > --- a/lib/librte_ether/rte_ethdev.h > > > +++ b/lib/librte_ether/rte_ethdev.h > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > /**< queue state event (enabled/disabled) > > */ > > > RTE_ETH_EVENT_INTR_RESET, > > > /**< reset interrupt event, sent to VF on PF reset */ > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > }; > > > > > > +/** > > > + * Response sent back to ixgbe driver from user app after callback > > > + */ > > > +enum rte_eth_mb_event_rsp { > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK > > */ > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and > > NACK */ > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request > > */ > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ > > > +}; > > > > Do we really need to define the specifics of PF to VF MBOX communication > > in normative ethdev specification? > > Each drivers may have different PF to VF MBOX definitions so it may not be > > very portable. > > What is the use-case here? If its for VF configuration, I think we can > > do it as separate 'sync' functions for each functionality so that > > PMDs will have room hiding the specifics on MBOX definitions. >
On Tue, Sep 13, 2016 at 02:05:49PM +0000, ZELEZNIAK, ALEX wrote: > Idea here is not to allow VM to control policies assigned to it for security > and other reasons. PF is controlled by host and dictates what VM can and > can't do in regards of setting VF parameters. I think the proposed scheme, The VM does not take any action on its own. The VM will just follow what the centralized entity to do so. I think if you are planning to support different varieties of PMD then this could be an option.However, if you wish to support only a subset of PMDs then PF MBOX based scheme may be enough. In any case, I think exposing the fine details of PF/VF MBOX scheme in the ethdev spec is not a good idea. > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Tuesday, September 13, 2016 4:46 AM > > To: ZELEZNIAK, ALEX <az5157@att.com> > > Cc: Bernard Iremonger <bernard.iremonger@intel.com>; > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > callback functions > > > > On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > > > Use case could be to inform application managing SRIOV about VM's > > intention > > > to modify parameters like add VLAN which might not be the one which is > > > assigned to VF or inform about VF reset and reapply settings like > > strip/insert > > > VLAN id based on policy. > > > > Is there any other way(more portable way) where we can realize the same > > use case? > > > > Something like, > > > > 1) The assigned VM operates/control the VF > > 2) A centralized entity post messages through UNIX socket or > > something(like vhost user communicates with VM). > > On message receive, VM can take necessary action on assigned VF. > > > > This will avoid the need of defining specifics of PF to VF mailbox > > communication in normative ethdev specification. > > > > And I guess it will work almost the PMD drivers as their is no > > PMD specific work here. > > > > Just a thought. > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Friday, September 09, 2016 10:11 AM > > > > To: Bernard Iremonger <bernard.iremonger@intel.com> > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > > > ZELEZNIAK, ALEX <az5157@att.com> > > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > > > callback functions > > > > > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > > > add _rte_eth_dev_callback_process_vf function. > > > > > add _rte_eth_dev_callback_process_generic function > > > > > > > > > > Adding a callback to the user application on VF to PF mailbox message, > > > > > allows passing information to the application controlling the PF > > > > > when a VF mailbox event message is received, such as VF reset. > > > > > > > > > > Signed-off-by: azelezniak <alexz@att.com> > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > > > --- > > > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > > > lib/librte_ether/rte_ethdev.h | 61 > > > > ++++++++++++++++++++++++++++++++++ > > > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > > > 3 files changed, 85 insertions(+) > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > b/lib/librte_ether/rte_ethdev.c > > > > > index f62a9ec..1388ea3 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > @@ -2690,6 +2690,20 @@ void > > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > > enum rte_eth_event_type event) > > > > > { > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, NULL); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, param); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > struct rte_eth_dev_callback *cb_lst; > > > > > struct rte_eth_dev_callback dev_cb; > > > > > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > > > rte_eth_dev *dev, > > > > > continue; > > > > > dev_cb = *cb_lst; > > > > > cb_lst->active = 1; > > > > > + if (param != NULL) > > > > > + dev_cb.cb_arg = (void *) param; > > > > > + > > > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > > > dev_cb.cb_arg); > > > > > diff --git a/lib/librte_ether/rte_ethdev.h > > b/lib/librte_ether/rte_ethdev.h > > > > > index b0fe033..4fb0b9c 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.h > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > > > /**< queue state event (enabled/disabled) > > > > */ > > > > > RTE_ETH_EVENT_INTR_RESET, > > > > > /**< reset interrupt event, sent to VF on PF reset */ > > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > > > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > > > }; > > > > > > > > > > +/** > > > > > + * Response sent back to ixgbe driver from user app after callback > > > > > + */ > > > > > +enum rte_eth_mb_event_rsp { > > > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK > > > > */ > > > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and > > > > NACK */ > > > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request > > > > */ > > > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ > > > > > +}; > > > > > > > > Do we really need to define the specifics of PF to VF MBOX > > communication > > > > in normative ethdev specification? > > > > Each drivers may have different PF to VF MBOX definitions so it may not > > be > > > > very portable. > > > > What is the use-case here? If its for VF configuration, I think we can > > > > do it as separate 'sync' functions for each functionality so that > > > > PMDs will have room hiding the specifics on MBOX definitions. > > >
Hi Jerin, Thomas, <snip> > -----Original Message----- > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > callback functions > > On Tue, Sep 13, 2016 at 02:05:49PM +0000, ZELEZNIAK, ALEX wrote: > > Idea here is not to allow VM to control policies assigned to it for > > security and other reasons. PF is controlled by host and dictates what > > VM can and can't do in regards of setting VF parameters. > > I think the proposed scheme, The VM does not take any action on its own. > The VM will just follow what the centralized entity to do so. > I think if you are planning to support different varieties of PMD then this > could be an option. However, if you wish to support only a subset of PMDs > then PF MBOX based scheme may be enough. > In any case, I think exposing the fine details of PF/VF MBOX scheme in the > ethdev spec is not a good idea. The AT&T requirement is to have the application controlling the PF (for example VFD) receive information via a callback when a VF mailbox event is received (for example IXGBE_VF_SET_VLAN) to decide whether to allow or deny a VF request. Do you have any suggestions on how the above requirement can be met without "exposing the fine details of PF/VF MBOX scheme in the ethdev spec". Regards, Bernard. > > > -----Original Message----- > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > Sent: Tuesday, September 13, 2016 4:46 AM > > > To: ZELEZNIAK, ALEX <az5157@att.com> > > > Cc: Bernard Iremonger <bernard.iremonger@intel.com>; > > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add > > > internal callback functions > > > > > > On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > > > > Use case could be to inform application managing SRIOV about VM's > > > intention > > > > to modify parameters like add VLAN which might not be the one > > > > which is assigned to VF or inform about VF reset and reapply > > > > settings like > > > strip/insert > > > > VLAN id based on policy. > > > > > > Is there any other way(more portable way) where we can realize the > > > same use case? > > > > > > Something like, > > > > > > 1) The assigned VM operates/control the VF > > > 2) A centralized entity post messages through UNIX socket or > > > something(like vhost user communicates with VM). > > > On message receive, VM can take necessary action on assigned VF. > > > > > > This will avoid the need of defining specifics of PF to VF mailbox > > > communication in normative ethdev specification. > > > > > > And I guess it will work almost the PMD drivers as their is no PMD > > > specific work here. > > > > > > Just a thought. > > > > > > > > > > > > -----Original Message----- > > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > > Sent: Friday, September 09, 2016 10:11 AM > > > > > To: Bernard Iremonger <bernard.iremonger@intel.com> > > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > > > > ZELEZNIAK, ALEX <az5157@att.com> > > > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add > > > > > internal callback functions > > > > > > > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > > > > add _rte_eth_dev_callback_process_vf function. > > > > > > add _rte_eth_dev_callback_process_generic function > > > > > > > > > > > > Adding a callback to the user application on VF to PF mailbox > > > > > > message, allows passing information to the application > > > > > > controlling the PF when a VF mailbox event message is received, > such as VF reset. > > > > > > > > > > > > Signed-off-by: azelezniak <alexz@att.com> > > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > > > > --- > > > > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > > > > lib/librte_ether/rte_ethdev.h | 61 > > > > > ++++++++++++++++++++++++++++++++++ > > > > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > > > > 3 files changed, 85 insertions(+) > > > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > b/lib/librte_ether/rte_ethdev.c > > > > > > index f62a9ec..1388ea3 100644 > > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > > @@ -2690,6 +2690,20 @@ void > > > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > > > enum rte_eth_event_type event) { > > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, > > > > > > +NULL); } > > > > > > + > > > > > > +void > > > > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > > > > + enum rte_eth_event_type event, void *param) { > > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, > > > > > > +param); } > > > > > > + > > > > > > +void > > > > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev > *dev, > > > > > > + enum rte_eth_event_type event, void *param) { > > > > > > struct rte_eth_dev_callback *cb_lst; > > > > > > struct rte_eth_dev_callback dev_cb; > > > > > > > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > > > > rte_eth_dev *dev, > > > > > > continue; > > > > > > dev_cb = *cb_lst; > > > > > > cb_lst->active = 1; > > > > > > + if (param != NULL) > > > > > > + dev_cb.cb_arg = (void *) param; > > > > > > + > > > > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > > > > dev_cb.cb_arg); > > > > > > diff --git a/lib/librte_ether/rte_ethdev.h > > > b/lib/librte_ether/rte_ethdev.h > > > > > > index b0fe033..4fb0b9c 100644 > > > > > > --- a/lib/librte_ether/rte_ethdev.h > > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > > > > /**< queue state event > (enabled/disabled) > > > > > */ > > > > > > RTE_ETH_EVENT_INTR_RESET, > > > > > > /**< reset interrupt event, sent to VF on PF > reset */ > > > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing > callback > > > > > > +*/ > > > > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > > > > }; > > > > > > > > > > > > +/** > > > > > > + * Response sent back to ixgbe driver from user app after > > > > > > +callback */ enum rte_eth_mb_event_rsp { > > > > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request > and ACK > > > > > */ > > > > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request > and > > > > > NACK */ > > > > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox > request > > > > > */ > > > > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum > */ > > > > > > +}; > > > > > > > > > > Do we really need to define the specifics of PF to VF MBOX > > > communication > > > > > in normative ethdev specification? > > > > > Each drivers may have different PF to VF MBOX definitions so it > > > > > may not > > > be > > > > > very portable. > > > > > What is the use-case here? If its for VF configuration, I think > > > > > we can do it as separate 'sync' functions for each functionality > > > > > so that PMDs will have room hiding the specifics on MBOX definitions. > > > >
Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Wednesday, September 14, 2016 12:28 PM > To: ZELEZNIAK, ALEX <az5157@att.com> > Cc: Iremonger, Bernard <bernard.iremonger@intel.com>; Shah, Rahul R > <rahul.r.shah@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; > dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > callback functions > > On Tue, Sep 13, 2016 at 02:05:49PM +0000, ZELEZNIAK, ALEX wrote: > > Idea here is not to allow VM to control policies assigned to it for > > security and other reasons. PF is controlled by host and dictates what > > VM can and can't do in regards of setting VF parameters. > > I think the proposed scheme, The VM does not take any action on its own. > The VM will just follow what the centralized entity to do so. > I think if you are planning to support different varieties of PMD then this > could be an option.However, if you wish to support only a subset of PMDs > then PF MBOX based scheme may be enough. > In any case, I think exposing the fine details of PF/VF MBOX scheme in the > ethdev spec is not a good idea. I have reworked these patches (1/5 and 2/5) using the new rte_pmd_ixgbe.h file and submitted as a separate patchset. [PATCH v3 0/2] add callbacks for VF management http://dpdk.org/dev/patchwork/patch/16321/ http://dpdk.org/dev/patchwork/patch/16322/ Regards, Bernard. > > > -----Original Message----- > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > Sent: Tuesday, September 13, 2016 4:46 AM > > > To: ZELEZNIAK, ALEX <az5157@att.com> > > > Cc: Bernard Iremonger <bernard.iremonger@intel.com>; > > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add > > > internal callback functions > > > > > > On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > > > > Use case could be to inform application managing SRIOV about VM's > > > intention > > > > to modify parameters like add VLAN which might not be the one > > > > which is assigned to VF or inform about VF reset and reapply > > > > settings like > > > strip/insert > > > > VLAN id based on policy. > > > > > > Is there any other way(more portable way) where we can realize the > > > same use case? > > > > > > Something like, > > > > > > 1) The assigned VM operates/control the VF > > > 2) A centralized entity post messages through UNIX socket or > > > something(like vhost user communicates with VM). > > > On message receive, VM can take necessary action on assigned VF. > > > > > > This will avoid the need of defining specifics of PF to VF mailbox > > > communication in normative ethdev specification. > > > > > > And I guess it will work almost the PMD drivers as their is no PMD > > > specific work here. > > > > > > Just a thought. > > > > > > > > > > > > -----Original Message----- > > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > > Sent: Friday, September 09, 2016 10:11 AM > > > > > To: Bernard Iremonger <bernard.iremonger@intel.com> > > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > > > > ZELEZNIAK, ALEX <az5157@att.com> > > > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add > > > > > internal callback functions > > > > > > > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > > > > add _rte_eth_dev_callback_process_vf function. > > > > > > add _rte_eth_dev_callback_process_generic function > > > > > > > > > > > > Adding a callback to the user application on VF to PF mailbox > > > > > > message, allows passing information to the application > > > > > > controlling the PF when a VF mailbox event message is received, > such as VF reset. > > > > > > > > > > > > Signed-off-by: azelezniak <alexz@att.com> > > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > > > > --- > > > > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > > > > lib/librte_ether/rte_ethdev.h | 61 > > > > > ++++++++++++++++++++++++++++++++++ > > > > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > > > > 3 files changed, 85 insertions(+) > > > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > b/lib/librte_ether/rte_ethdev.c > > > > > > index f62a9ec..1388ea3 100644 > > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > > @@ -2690,6 +2690,20 @@ void > > > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > > > enum rte_eth_event_type event) { > > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, > > > > > > +NULL); } > > > > > > + > > > > > > +void > > > > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > > > > + enum rte_eth_event_type event, void *param) { > > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, > > > > > > +param); } > > > > > > + > > > > > > +void > > > > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev > *dev, > > > > > > + enum rte_eth_event_type event, void *param) { > > > > > > struct rte_eth_dev_callback *cb_lst; > > > > > > struct rte_eth_dev_callback dev_cb; > > > > > > > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > > > > rte_eth_dev *dev, > > > > > > continue; > > > > > > dev_cb = *cb_lst; > > > > > > cb_lst->active = 1; > > > > > > + if (param != NULL) > > > > > > + dev_cb.cb_arg = (void *) param; > > > > > > + > > > > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > > > > dev_cb.cb_arg); > > > > > > diff --git a/lib/librte_ether/rte_ethdev.h > > > b/lib/librte_ether/rte_ethdev.h > > > > > > index b0fe033..4fb0b9c 100644 > > > > > > --- a/lib/librte_ether/rte_ethdev.h > > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > > > > /**< queue state event > (enabled/disabled) > > > > > */ > > > > > > RTE_ETH_EVENT_INTR_RESET, > > > > > > /**< reset interrupt event, sent to VF on PF > reset */ > > > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing > callback > > > > > > +*/ > > > > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > > > > }; > > > > > > > > > > > > +/** > > > > > > + * Response sent back to ixgbe driver from user app after > > > > > > +callback */ enum rte_eth_mb_event_rsp { > > > > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request > and ACK > > > > > */ > > > > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request > and > > > > > NACK */ > > > > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox > request > > > > > */ > > > > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum > */ > > > > > > +}; > > > > > > > > > > Do we really need to define the specifics of PF to VF MBOX > > > communication > > > > > in normative ethdev specification? > > > > > Each drivers may have different PF to VF MBOX definitions so it > > > > > may not > > > be > > > > > very portable. > > > > > What is the use-case here? If its for VF configuration, I think > > > > > we can do it as separate 'sync' functions for each functionality > > > > > so that PMDs will have room hiding the specifics on MBOX definitions. > > > >
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index f62a9ec..1388ea3 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -2690,6 +2690,20 @@ void _rte_eth_dev_callback_process(struct rte_eth_dev *dev, enum rte_eth_event_type event) { + return _rte_eth_dev_callback_process_generic(dev, event, NULL); +} + +void +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, + enum rte_eth_event_type event, void *param) +{ + return _rte_eth_dev_callback_process_generic(dev, event, param); +} + +void +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, + enum rte_eth_event_type event, void *param) +{ struct rte_eth_dev_callback *cb_lst; struct rte_eth_dev_callback dev_cb; @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct rte_eth_dev *dev, continue; dev_cb = *cb_lst; cb_lst->active = 1; + if (param != NULL) + dev_cb.cb_arg = (void *) param; + rte_spinlock_unlock(&rte_eth_dev_cb_lock); dev_cb.cb_fn(dev->data->port_id, dev_cb.event, dev_cb.cb_arg); diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index b0fe033..4fb0b9c 100644 --- a/lib/librte_ether/rte_ethdev.h +++ b/lib/librte_ether/rte_ethdev.h @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { /**< queue state event (enabled/disabled) */ RTE_ETH_EVENT_INTR_RESET, /**< reset interrupt event, sent to VF on PF reset */ + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ RTE_ETH_EVENT_MAX /**< max value of this enum */ }; +/** + * Response sent back to ixgbe driver from user app after callback + */ +enum rte_eth_mb_event_rsp { + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK */ + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and NACK */ + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request */ + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ +}; + +struct rte_eth_mb_event_param { + uint16_t vfid; + uint16_t msg_type; + uint16_t retval; + void *userdata; +}; + typedef void (*rte_eth_dev_cb_fn)(uint8_t port_id, \ enum rte_eth_event_type event, void *cb_arg); /**< user application callback to be registered for interrupts */ @@ -3114,6 +3132,49 @@ void _rte_eth_dev_callback_process(struct rte_eth_dev *dev, enum rte_eth_event_type event); /** + * @internal Executes all the user application registered callbacks for + * the specific device where parameter have to be passed to user application. + * It is for DPDK internal user only. User application should not call it + * directly. + * + * @param dev + * Pointer to struct rte_eth_dev. + * @param event + * Eth device interrupt event type. + * + * @param param + * parameters to pass back to user application. + * + * @return + * void + */ + +void +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, + enum rte_eth_event_type event, void *param); + +/** + * @internal Executes all the user application registered callbacks. Used by: + * _rte_eth_dev_callback_process and _rte_eth_dev_callback_process_vf + * It is for DPDK internal user only. User application should not call it + * directly. + * + * @param dev + * Pointer to struct rte_eth_dev. + * @param event + * Eth device interrupt event type. + * + * @param param + * parameters to pass back to user application. + * + * @return + * void + */ +void +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, + enum rte_eth_event_type event, void *param); + +/** * When there is no rx packet coming in Rx Queue for a long time, we can * sleep lcore related to RX Queue for power saving, and enable rx interrupt * to be triggered when rx packect arrives. diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map index 45ddf44..cb7ef15 100644 --- a/lib/librte_ether/rte_ether_version.map +++ b/lib/librte_ether/rte_ether_version.map @@ -139,3 +139,10 @@ DPDK_16.07 { rte_eth_dev_get_port_by_name; rte_eth_xstats_get_names; } DPDK_16.04; + +DPDK_16.11 { + global: + + _rte_eth_dev_callback_process_generic; + _rte_eth_dev_callback_process_vf; +} DPDK_16.07;