DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management
@ 2016-09-28 19:25 ZELEZNIAK, ALEX
  0 siblings, 0 replies; 33+ messages in thread
From: ZELEZNIAK, ALEX @ 2016-09-28 19:25 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Ananyev, Konstantin, Iremonger, Bernard, Richardson, Bruce, dev,
	Jerin Jacob, Shah, Rahul R, Lu, Wenzhuo





----------------------------------------

From: "az5157@att.com<mailto:az5157@att.com>" <az5157@att.com<mailto:az5157@att.com>>
Date: Wednesday, September 28, 2016 at 12:23:06 PM
To: "Thomas Monjalon" <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com<mailto:konstantin.ananyev@intel.com>>, "Iremonger, Bernard" <bernard.iremonger@intel.com<mailto:bernard.iremonger@intel.com>>, "Richardson, Bruce" <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>>, "dev@dpdk.org<mailto:dev@dpdk.org>" <dev@dpdk.org<mailto:dev@dpdk.org>>, "Jerin Jacob" <jerin.jacob@caviumnetworks.com<mailto:jerin.jacob@caviumnetworks.com>>, "Shah, Rahul R" <rahul.r.shah@intel.com<mailto:rahul.r.shah@intel.com>>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>>
Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management

>
> 2016-09-28 16:52, Ananyev, Konstantin:
> >
> > >
> > > 2016-09-28 14:30, Ananyev, Konstantin:
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>]
> > > > > 2016-09-28 13:26, Ananyev, Konstantin:
> > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>]
> > > > > > > 2016-09-28 11:23, Ananyev, Konstantin:
> > > > > > > > If we  this way (force user to include driver specific headers
> > > > > > > > and call driver specific functions), how you guys plan to make this functionality available for multiple driver types.
> > > > > > >
> > > > > > > Multiple drivers won't have exactly the same specific features.
> > > > > > > But yes, there are some things common to several Intel NICs.
> > > > > > >
> > > > > > > > From discussion with Bernard  understand that customers would need similar functionality for i40e.
> > > > > > > > Does it mean that they'll have to re-implement this part of their code again?
> > > > > > > > Or would have to create (and maintain) their own shim layer that would provide some s of abstraction?
> > > > > > > > Basically their own version of rte_ethdev?
> > > > > > >
> > > > > > > No definitive answer.
> > > > > > > But we can argue the contrary: how to handle a generic API which
> > > > > > > is implemented only in 1 or 2 drivers? If the application tries to use it, we can imagine that a specific range of hardware is
> > > expected.
> > > > > >
> > > > > > Yes, as I understand, it is a specific subset of supported HW (just Inel NICs for now, but different models/drivers).
> > > > > > Obviously users would like to have an ability to run their app on all HW from this subset without rebuilding/implementing the
> > > app.
> > > > > >
> > > > > > >
> > > > > > > I think it is an important question.
> > > > > > > Previously we had the issue of having some API which are too
> > > > > > > specific and need a rework to be used with other NICs. In order
> > > > > > > to avoid such rework and API break, we can try to make them
> > > > > > > available in a driver-specific or vendor-specific staging area,
> > > > > > > waiting for
> > > > > a later generalization.
> > > > > >
> > > > > > Could you remind me why you guys were that opposed to ioctl style approach?
> > > > > > It is not my favorite thing either, but it seems pretty generic way to handle such situations.
> > > > >
> > > > > We prefer having well-defined functions instead of opaque ioctl-style encoding.
> > > > > And it was not clear what is the benefit of ioctl.
> > > > > Now I think I understand you would like to have a common ioctl service for features available on 2 drivers. Right?
> > > >
> > > > Yes.
> > > >
> > > > > Example (trying to  read your mind):
> > > > >  rte_ethdev_ioctl(port_id, <TLV encoding VF_PING service and VF id>); instead of
> > > > >  rte_pmd_ixgbe_vf_ping(port_id, vf_id);
> > > > >  rte_pmd_i40e_vf_ping(port_id, vf_id); Please confirm I understand
> > > > > what you are thinking about.
> > > >
> > > > Yep, you read my mind correctly :)
> > >
> > > Both could coexist (if ioctl was accepted by community).
> >
> > True.
> >
> > > What about starting to implement the PMD functions and postpone ioctl to later with a dedicated thread?
> >
> > You mean something like:
> > - 16.11: implement rte_pmd_ixgbe_vf_ping()
> > - 17.02:
> >        a) implement rte_pmd_i40e_vf_ping()
> >        b) introduce ioctl PMD API
> >        c) make possible to vf_ping via ioctl API
> > ?
> > If so, then it sounds like reasonable approach to me.
> > Though would be inserting to hear what other guys think.
>
> Yes.
> I would just add that we have to start a discussion thread to decide
> wether we'll add an ioctl call in 17.02 or not.
>

Looks good to me.
Thanks,
Alex Z.

________________________________

From: "az5157@att.com" <az5157@att.com<mailto:az5157@att.com>>
Date: Wednesday, September 28, 2016 at 12:23:06 PM
To: "Thomas Monjalon" <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com<mailto:konstantin.ananyev@intel.com>>, "Iremonger, Bernard" <bernard.iremonger@intel.com<mailto:bernard.iremonger@intel.com>>, "Richardson, Bruce" <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>>, "dev@dpdk.org" <dev@dpdk.org<mailto:dev@dpdk.org>>, "Jerin Jacob" <jerin.jacob@caviumnetworks.com<mailto:jerin.jacob@caviumnetworks.com>>, "Shah, Rahul R" <rahul.r.shah@intel.com<mailto:rahul.r.shah@intel.com>>, "Lu, Wenzhuo" <wenzhuo.lu@intel.com<mailto:wenzhuo.lu@intel.com>>
Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management


^ permalink raw reply	[flat|nested] 33+ messages in thread
* [dpdk-dev] [RFC PATCH 0/5] add API's for VF management
@ 2016-08-18 13:48 Bernard Iremonger
  2016-08-26  9:10 ` [dpdk-dev] [RFC PATCH v2 " Bernard Iremonger
  0 siblings, 1 reply; 33+ messages in thread
From: Bernard Iremonger @ 2016-08-18 13:48 UTC (permalink / raw)
  To: rahul.r.shah, wenzhuo.lu, dev; +Cc: Bernard Iremonger

This RFC patchset contains new DPDK API's requested by AT&T for use
with the Virtual Function Daemon (VFD).

The need to configure and manage VF's on a NIC has grown to the
point where AT&T have devloped a DPDK based tool, VFD, to do this.

This RFC proposes to add the following API extensions to DPDK:
  mailbox communication callback support
  VF configuration

Nine new functions have been added to the eth_dev_ops structure.
Corresponding functions have been added to the ixgbe PMD for the
Niantic NIC.

Two new callback functions have been added.
Changes have been made to the ixgbe_rcv_msg_from_vf function to
use the callback functions.

Changes have been made to testpmd to facilitate testing of the new API's.
The testpmd documentation has been updated to document the testpmd changes.

Note:
Adding new functions to the eth_dev_ops structure will cause an
ABI breakage.

Bernard Iremonger (5):
  librte_ether: add internal callback functions
  net/ixgbe: add callback to user app on VF to PF mbox msg
  librte_ether: add API's for VF management
  net/ixgbe: add functions for VF management
  app/test_pmd: add tests for new API's

 app/test-pmd/cmdline.c                      | 700 ++++++++++++++++++++++++++++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  68 ++-
 drivers/net/ixgbe/ixgbe_ethdev.c            | 179 +++++++
 drivers/net/ixgbe/ixgbe_pf.c                |  39 +-
 lib/librte_ether/rte_ethdev.c               | 176 +++++++
 lib/librte_ether/rte_ethdev.h               | 284 +++++++++++
 lib/librte_ether/rte_ether_version.map      |  16 +
 7 files changed, 1455 insertions(+), 7 deletions(-)

-- 
2.9.0

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2016-09-30  9:21 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-28 19:25 [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management ZELEZNIAK, ALEX
  -- strict thread matches above, loose matches on Subject: below --
2016-08-18 13:48 [dpdk-dev] [RFC PATCH 0/5] " Bernard Iremonger
2016-08-26  9:10 ` [dpdk-dev] [RFC PATCH v2 " Bernard Iremonger
2016-08-26  9:10   ` [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: " 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

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).