From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl
Date: Thu, 28 Aug 2014 11:48:53 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <1793573.SnjKVZ6loZ@xps13>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 28, 2014 11:56 AM
> To: Wu, Jingjing
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl
>
> 2014-08-28 03:30, Wu, Jingjing:
> > We want to implement several common API for NIC specific features,
> > to avoid creating quite a lot of ops in 'struct eth_dev_ops'.
> > The idea came from ioctl.
>
> The approach can be interesting.
>
> > Because about flow director feature, there is large gap between i40e
> > and ixgbe. The existed flow director APIs looks specific to IXGBE,
> > so I choose this new API to implement i40e's flow director feature.
>
> The API is not OK for you so you create another one.
> I'm OK to change APIs but you should remove the old one, or at least,
> implement your new API in existing drivers to allow deprecation of the
> old API.
> I think it would help if you start by doing ixgbe work and then apply it
> to i40e.
>
> > The API is like below:
> > typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,
> > enum rte_eth_command cmd,
> > void *arg);
> > Define a head file called rte_i40e.h in lib/librte_pmd_i40e, which contains
> > the definition about structures specific to i40e, linked to the arg
> > parameters above.
> > Define a head file called rte_eth_features.h in lib/librte_ether, which
> > contains the commands' definition linked to cmd parameters above.
>
> Why creating a rte_eth_features.h? Don't you think rte_ethdev.h is a good place?
As I remember the long term idea was
(Jingjing please correct me, if I am wrong here):
Keep rte_ethdev.h for generic API.
Put features specific for different NICs into rte_eth_features.h
To make things clearer and avoid polluting of rte_ethdev.h.
Provide API for the upper layer to query list of specific features(commands) supported by the underlying device.
Something like:
rte_eth_dev_get_rx_filter_supported(port, ...);
And ioctl-type API to configure HW specific features:
rte_eth_dev_rx_classification_filter_ctl(port, cmd, cmd_spedific_arg);
So, instead of application knows in advance "which specific NIC it is using",
application would query which features/commannds the NIC provides and then configure them appropriately.
>
> > And if user want to use i40e specific features, then the head file
> > rte_i40e.h need to be included user's application, for example, test-pmd.
> > And user can encode these structures and call XXX_ctl API to configure
> > their features.
>
> OK, but the question is to know what is a specific feature?
> I don't think flow director is a specific feature. We shouldn't have
> to care if port is i40e or ixgbe to setup flow director.
> Is it possible to have a common API and maybe an inheritance of the
> common structure with PMD specific fields?
>
> Example:
>
> struct fdir_entry {
> fdir_input input;
> fdir_action action;
> enum rte_driver driver;
> };
> fdir_entry_generic fdir_entry = {.driver = RTE_DRIVER_GENERIC};
> filter_ctl(port, FDIR_RULE_ADD, fdir_entry);
>
> struct i40e_fdir_entry {
> struct fdir_entry generic;
> i40e_fdir_input i40e_input;
> };
>
> So i40e_input will be handled by the PMD if driver == RTE_DRIVER_I40E.
>
> It's just an idea, comments are welcome.
>
> --
> Thomas
next prev parent reply other threads:[~2014-08-28 11:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 2:13 [dpdk-dev] [PATCH v2 0/7] Support flow director programming on fortville Jingjing Wu
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 1/7] i40e: flow director resource reserve and initialize on i40e Jingjing Wu
2014-08-27 14:17 ` Thomas Monjalon
2014-08-28 2:56 ` Wu, Jingjing
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl Jingjing Wu
2014-08-27 14:22 ` Thomas Monjalon
2014-08-28 3:30 ` Wu, Jingjing
2014-08-28 10:55 ` Thomas Monjalon
2014-08-28 11:48 ` Ananyev, Konstantin [this message]
2014-08-28 14:07 ` Wu, Jingjing
2014-08-28 13:39 ` Wu, Jingjing
2014-08-28 14:20 ` Thomas Monjalon
2014-08-28 14:31 ` Wu, Jingjing
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 3/7] i40e: function implement in i40e for flow director filter programming Jingjing Wu
2014-08-27 14:24 ` Thomas Monjalon
2014-08-28 2:57 ` Wu, Jingjing
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 4/7] i40e: function implement in i40e for flow director flush and info get Jingjing Wu
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 5/7] fix the Marco conflict Jingjing Wu
2014-08-27 14:27 ` Thomas Monjalon
2014-08-28 3:39 ` Wu, Jingjing
2014-08-28 8:55 ` Thomas Monjalon
2014-08-28 14:37 ` Wu, Jingjing
2014-08-28 14:46 ` Thomas Monjalon
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 6/7] i40e: support FD ID report and match counter for i40e flow director Jingjing Wu
2014-08-27 2:13 ` [dpdk-dev] [PATCH v2 7/7]app/testpmd: add commands and config functions for i40e flow director support Jingjing Wu
2014-08-27 14:35 ` Thomas Monjalon
2014-08-27 16:54 ` Venkatesan, Venky
2014-08-28 3:51 ` Wu, Jingjing
2014-08-28 8:50 ` Thomas Monjalon
2014-08-28 9:01 ` Wu, Jingjing
2014-08-28 11:00 ` Thomas Monjalon
2014-08-28 11:30 ` Ananyev, Konstantin
2014-08-28 12:02 ` Thomas Monjalon
2014-09-24 4:52 ` [dpdk-dev] [PATCH v2 0/7] Support flow director programming on fortville Cao, Min
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=2601191342CEEE43887BDE71AB9772582135F39F@IRSMSX105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=thomas.monjalon@6wind.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).