From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "Shah, Rahul R" <rahul.r.shah@intel.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, "ZELEZNIAK, ALEX" <az5157@att.com>
Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions
Date: Mon, 3 Oct 2016 08:58:09 +0000 [thread overview]
Message-ID: <8CEF83825BEC744B83065625E567D7C21A08EA7F@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20160914112811.GA8364@localhost.localdomain>
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.
> > > >
next prev parent reply other threads:[~2016-10-03 8:58 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 13:48 [dpdk-dev] [RFC PATCH 0/5] add API's for VF management Bernard Iremonger
2016-08-18 13:48 ` [dpdk-dev] [RFC PATCH 1/5] librte_ether: add internal callback functions Bernard Iremonger
2016-08-18 13:48 ` [dpdk-dev] [RFC PATCH 2/5] net/ixgbe: add callback to user app on VF to PF mbox msg Bernard Iremonger
2016-08-18 13:48 ` [dpdk-dev] [RFC PATCH 3/5] librte_ether: add API's for VF management Bernard Iremonger
2016-08-18 13:48 ` [dpdk-dev] [RFC PATCH 4/5] net/ixgbe: add functions " Bernard Iremonger
2016-08-18 13:48 ` [dpdk-dev] [RFC PATCH 5/5] app/test_pmd: add tests for new API's Bernard Iremonger
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 0/5] add API's for VF management Bernard Iremonger
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions Bernard Iremonger
2016-09-09 14:10 ` Jerin Jacob
[not found] ` <3C0218D8B3DD114D8DBFE6B68141FBE3185F9FE7@MISOUT7MSGUSRDI.ITServices.sbc.com>
2016-09-13 8:45 ` Jerin Jacob
[not found] ` <3C0218D8B3DD114D8DBFE6B68141FBE3185FDCDC@MISOUT7MSGUSRDI.ITServices.sbc.com>
2016-09-14 11:28 ` Jerin Jacob
2016-09-22 11:25 ` Iremonger, Bernard
2016-10-03 8:58 ` Iremonger, Bernard [this message]
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 2/5] net/ixgbe: add callback to user app on VF to PF mbox msg Bernard Iremonger
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management Bernard Iremonger
2016-09-09 14:22 ` Jerin Jacob
2016-09-12 16:28 ` Iremonger, Bernard
2016-09-13 9:24 ` Thomas Monjalon
2016-09-15 16:46 ` Iremonger, Bernard
2016-09-22 17:04 ` Thomas Monjalon
2016-09-23 9:20 ` Bruce Richardson
2016-09-23 9:36 ` Thomas Monjalon
2016-09-23 9:53 ` Richardson, Bruce
2016-09-23 13:15 ` Thomas Monjalon
2016-09-23 17:02 ` Iremonger, Bernard
2016-09-23 17:18 ` Thomas Monjalon
2016-09-26 15:37 ` Iremonger, Bernard
2016-09-26 16:59 ` Thomas Monjalon
2016-09-27 10:31 ` Iremonger, Bernard
2016-09-27 13:01 ` Bruce Richardson
2016-09-27 14:13 ` Iremonger, Bernard
2016-09-28 11:23 ` Ananyev, Konstantin
2016-09-28 12:31 ` Iremonger, Bernard
2016-09-28 13:01 ` Richardson, Bruce
2016-09-28 13:03 ` Thomas Monjalon
2016-09-28 13:26 ` Ananyev, Konstantin
2016-09-28 14:24 ` Thomas Monjalon
2016-09-28 14:30 ` Ananyev, Konstantin
2016-09-28 14:48 ` Iremonger, Bernard
2016-09-28 15:00 ` Thomas Monjalon
2016-09-28 15:24 ` Iremonger, Bernard
2016-09-28 14:59 ` Thomas Monjalon
2016-09-28 16:52 ` Ananyev, Konstantin
2016-09-28 18:02 ` Thomas Monjalon
2016-09-30 9:21 ` Bruce Richardson
2016-09-23 10:34 ` Bruce Richardson
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 4/5] net/ixgbe: add functions " Bernard Iremonger
2016-08-26 9:10 ` [dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for new API's Bernard Iremonger
2016-09-11 12:35 ` Yuanhan Liu
2016-09-12 15:57 ` Iremonger, Bernard
2016-09-13 4:34 ` Yuanhan Liu
2016-09-13 8:38 ` Iremonger, Bernard
2016-09-13 8:42 ` Yuanhan Liu
2016-09-07 9:18 ` [dpdk-dev] [RFC PATCH v2 0/5] add API's for VF management Pattan, Reshma
2016-09-09 8:49 ` Pattan, Reshma
2016-09-09 13:02 ` Thomas Monjalon
2016-09-16 11:05 ` [dpdk-dev] [PATCH v3 0/3] " Bernard Iremonger
2016-09-16 11:05 ` [dpdk-dev] [PATCH v3 1/3] librte_ether: " Bernard Iremonger
2016-09-16 11:05 ` [dpdk-dev] [PATCH v3 2/3] net/ixgbe: add functions " Bernard Iremonger
2016-09-16 11:05 ` [dpdk-dev] [PATCH v3 3/3] app/test_pmd: add tests for new API's Bernard Iremonger
2016-09-16 14:15 ` [dpdk-dev] [PATCH v3 0/3] add API's for VF management Bernard Iremonger
2016-09-21 10:20 ` [dpdk-dev] [PATCH v4 " Bernard Iremonger
2016-09-29 14:16 ` [dpdk-dev] [PATCH v5 " Bernard Iremonger
2016-09-30 10:30 ` [dpdk-dev] [PATCH v6 0/2] " Bernard Iremonger
2016-09-30 10:30 ` [dpdk-dev] [PATCH v6 1/2] net/ixgbe: " Bernard Iremonger
2016-10-07 10:45 ` [dpdk-dev] [PATCH v7 0/2] " Bernard Iremonger
2016-10-07 10:45 ` [dpdk-dev] [PATCH v7 1/2] net/ixgbe: " Bernard Iremonger
2016-10-07 10:45 ` [dpdk-dev] [PATCH v7 2/2] app/test_pmd: add tests for new API's Bernard Iremonger
2016-10-11 15:09 ` Ferruh Yigit
2016-10-11 15:41 ` Thomas Monjalon
2016-10-11 15:51 ` Iremonger, Bernard
2016-10-11 16:32 ` Thomas Monjalon
2016-10-11 16:35 ` Iremonger, Bernard
2016-10-12 2:05 ` De Lara Guarch, Pablo
2016-10-12 15:00 ` Iremonger, Bernard
2016-09-30 10:30 ` [dpdk-dev] [PATCH v6 " Bernard Iremonger
2016-09-29 14:16 ` [dpdk-dev] [PATCH v5 1/3] librte_ether: add API for VF management Bernard Iremonger
2016-09-29 14:30 ` Thomas Monjalon
2016-09-29 15:16 ` Iremonger, Bernard
2016-09-29 16:19 ` Thomas Monjalon
2016-09-29 16:38 ` Iremonger, Bernard
2016-09-29 16:45 ` Thomas Monjalon
2016-09-29 14:16 ` [dpdk-dev] [PATCH v5 2/3] net/ixgbe: add API's " Bernard Iremonger
2016-09-29 16:11 ` Reshma Pattan
2016-09-29 16:32 ` Iremonger, Bernard
2016-09-29 16:16 ` Pattan, Reshma
2016-09-29 16:30 ` Iremonger, Bernard
2016-09-29 14:16 ` [dpdk-dev] [PATCH v5 3/3] app/test_pmd: add tests for new API's Bernard Iremonger
2016-09-21 10:20 ` [dpdk-dev] [PATCH v4 1/3] librte_ether: add API's for VF management Bernard Iremonger
2016-09-21 10:20 ` [dpdk-dev] [PATCH v4 2/3] net/ixgbe: add functions " Bernard Iremonger
2016-09-21 10:20 ` [dpdk-dev] [PATCH v4 3/3] app/test_pmd: add tests for new API's Bernard Iremonger
2016-09-16 14:15 ` [dpdk-dev] [PATCH v3 1/3] librte_ether: add API's for VF management Bernard Iremonger
2016-09-16 14:15 ` [dpdk-dev] [PATCH v3 2/3] net/ixgbe: add functions " Bernard Iremonger
2016-09-16 14:15 ` [dpdk-dev] [PATCH v3 3/3] app/test_pmd: add tests for new API's Bernard Iremonger
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=8CEF83825BEC744B83065625E567D7C21A08EA7F@IRSMSX108.ger.corp.intel.com \
--to=bernard.iremonger@intel.com \
--cc=az5157@att.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=rahul.r.shah@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).