DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	dev@dpdk.org, Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"Shah, Rahul R" <rahul.r.shah@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>, azelezniak <alexz@att.com>
Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management
Date: Fri, 30 Sep 2016 10:21:29 +0100	[thread overview]
Message-ID: <20160930092129.GA67296@bricha3-MOBL3> (raw)
In-Reply-To: <5655161.kOlSb9MaAr@xps13>

On Wed, Sep 28, 2016 at 08:02:21PM +0200, Thomas Monjalon wrote:
> 2016-09-28 16:52, Ananyev, Konstantin:
> > 
> > > 
> > > 2016-09-28 14:30, Ananyev, Konstantin:
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > > 2016-09-28 13:26, Ananyev, Konstantin:
> > > > > > From: Thomas Monjalon [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.

I still don't like IOCTLs as an option, I still think that they are awkward to
use and hinder code readability. Here is an addition suggestion to get people
thinking.

How about allowing a set of "vendor-specific" operations for each device. We
could do this using Bernard's suggestion of adding a set of additional 
function pointers to the device struct. The reason for doing this is that it
would allow us to group functionality into families of functionality, rather
than having to things either fully generically or specifically to each NIC. If
we look at the capabilities of most NICs, the other NICs which support similar
functions are generally other NICs from the same vendor. We could therefore
have ops common across ixgbe and i40e and other ops mlx4 and mlx5 drivers.

Could such a scheme work? Would it be worth doing?

/Bruce

  reply	other threads:[~2016-09-30  9:21 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-18 13:48 [dpdk-dev] [RFC PATCH 0/5] " 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
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 [this message]
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
2016-09-28 19:25 [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management ZELEZNIAK, ALEX

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=20160930092129.GA67296@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=alexz@att.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=rahul.r.shah@intel.com \
    --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).