From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] filter_ctl PMD API idea
Date: Thu, 16 Oct 2014 18:07:18 +0200 [thread overview]
Message-ID: <5217868.ALJSpaWAWD@xps13> (raw)
In-Reply-To: <9BB6961774997848B5B42BEC655768F8ADFFBD@SHSMSX104.ccr.corp.intel.com>
2014-09-08 15:06, Wu, Jingjing:
> Any comments or advises?
>
> Thanks!
>
> Fortville Filter features' development will be started based on this design this week.
Thanks Jingjing for explaining your plan before working on it.
There were no comment for 1 month so we'll assume everybody is OK.
Now your work is done and it's time to integrate it.
This design is used in many pending patchsets.
Now I wait for an unique patch out of any patchset in order to do some
comments about implementation.
Then it will be applied with i40e filters using this API.
So we'll have a new API implemented only for i40e.
But when DPDK 1.8 will be out, I expect to receive patches replacing old API
with this new one for igb and ixgbe.
Last request, please could you write a brief email summarizing all filters
of Intel NICs from an user perspective, and which ones are implemented in
DPDK, with which API?
Thanks
> > -----Original Message-----
> > Hi, all
> >
> > When we develop filters feature in i40e driver for Intel® Ethernet Controller XL710/X710
> > [Fortville] (For both 10G/40G), we found that there are lots of new filters, there are also
> > some changes on the existing filters, comparing to ixgbe.
> > If we keep the way to add new ops in rte_eth_dev for each new filter, it can work.
> > But we suggest to use a more generic API for all filters to avoid a superset dev_ops. It needs
> > to be cleaner and easy-to-use. There is a need for technical discussion.
> >
> > Here is the early design idea we are looking for comments.
> >
> > 1. Create two new APIs
> > -----------------------------------------------------
> > rte_eth_filter_supported(uint8_t port, uint16_t filter_type);
> > /* check whether this filter type is supported for the queried port */
> > rte_eth_filter_ctl(uint8_t port, uint16_t filter_type, uint16_t filter_op, void *arg);
> > /* configure filters, will call new ops eth_filter_ctl in eth_dev_ops */
> > -----------------------------------------------------
> >
> > 2. Define filter types, operations, and structures in new header file
> > lib/librte_eth/rte_eth_filter.h.
> > -----------------------------------------------------
> > #define RTE_ETH_FILTER_RSS 1
> > #define RTE_ETH_FILTER_SYN 2
> > #define RTE_ETH_FILTER_5TUPLE 3
> > #define RTE_ETH_FILTER_FDIR 4
> > .... <all other filter types we support>
> >
> > #define RTE_ETH_FILTER_OP_GET 1
> > #define RTE_ETH_FILTER_OP_ADD 2
> > #define RTE_ETH_FILTER_OP_DELETE 3
> > #define RTE_ETH_FILTER_OP_SET 4
> > ....< other operations if want to define>...
> >
> > /* structures defined for corresponding filter type and operation */
> > /* take RTE_ETH_FILTER_FDIR and OP_SET for example*/
> >
> > struct rte_eth_filter_fdir_cfg {
> > #define RTE_ETH_FILTER_FDIR_SET_MASK 0
> > #define RTE_ETH_FILTER_FDIR_SET_OFFSET 1
> > …… <other sub operations in this structure>
> > uint16_t cfg_type;
> > /* sub operation to defined what specific configuration it will take,
> > and which following fields are meaningful*/
> > ……
> > /* fields, can be a union or combine of required specific items*/
> > ……
> >
> > };
> >
> > -----------------------------------------------------
> > By this way, It is easy to add more filter types or operation in future.
> > And the difference among the same filter and operation can be distinguish by sub command
> > in defined structure, e.g. ”cfg_type” in above rte_eth_filter_fdir_cfg structure.
> >
> > 3. Define ops in driver (take i40e for example)
> > -----------------------------------------------------
> > static struct eth_dev_ops i40e_eth_dev_ops = {
> > . filter_ctl = i40e_filter_ctl,
> > };
> > -----------------------------------------------------
> > Then the functions in drivers can be implemented separately.
> >
> > 4. Use case In test-pmd/cmdline.c
> > -----------------------------------------------------
> > #include <rte_eth_filter.h>
> > /* add or change commands e.g. fdir_set (arg1) (arg2) …… */
> >
> > static void
> > cmd_fdir_parsed()
> > {
> > ……
> > /* take setting fdir mask for example*/
> > struct rte_eth_filter_fdir_cfg cfg;
> >
> > if (rte_eth_filter_supported(port, RTE_ETH_FILTER_FDIR)) {
> > cfg.cfg_type = RTE_ETH_FILTER_FDIR_SET_MASK;
> > /* fill the corresponding fields in cfg*/
> > ……
> > rte_eth_filter_ctl(port, RTE_ETH_FILTER_FDIR, RTE_ETH_FILTER_OP_SET, &cfg);
> > }
> > ……
> > }
> > -----------------------------------------------------
> >
> >
> > Any comments are welcome!
> >
> > At the time being, only Intel PMD is only available on dpdk.org. We are lack of understanding
> > on the other non-Intel PMD, the current design did not take them into account. But we are
> > looking for the inputs from those PMD developers, we strongly look forward to those PMD
> > are released as open source.
> >
> > Thanks!
> > Jingjing
next prev parent reply other threads:[~2014-10-16 15:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 12:04 Wu, Jingjing
2014-09-08 15:06 ` Wu, Jingjing
2014-10-16 16:07 ` Thomas Monjalon [this message]
2014-10-16 22:31 ` Wu, Jingjing
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=5217868.ALJSpaWAWD@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@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).