From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: 'Thomas Monjalon' <thomas.monjalon@6wind.com>
Cc: "'dev@dpdk.org'" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition
Date: Mon, 20 Oct 2014 03:38:07 +0000 [thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F8B1BFD9@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <9BB6961774997848B5B42BEC655768F8B104C0@SHSMSX104.ccr.corp.intel.com>
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Saturday, October 18, 2014 12:02 AM
> To: Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition
>
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Friday, October 17, 2014 5:08 PM
> > To: Wu, Jingjing
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs
> > definition
> >
> > 2014-10-17 07:29, Jingjing Wu:
> > > Define new APIs to support configure multi-kind filters using same
> > > APIs, instead of creating each API set for each kind of filter.
> > > - rte_eth_dev_filter_supported
> > > - rte_eth_dev_filter_ctrl
> > >
> > > Filter types, operations, and structures are defined specifically in
> > > new header file lib/librte_eth/rte_dev_ctrl.h.
> > >
> > > As to the implementation discussion, please refer to
> > > http://dpdk.org/ml/archives/dev/2014-September/005179.html
> > [...]
> > > --- /dev/null
> > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> >
> > Why this name? I think we can reserve this file for filtering API.
> > So rte_eth_rx_filter.h would be more appropriate.
> >
> Yes, the name rte_eth_ctrl.h can be extensible for XX_ctrl APIs.
> While the rte_eth_rx_filter.h only can be used for rx filter features.
>
> > > +/**
> > > + * All generic operations to filters */
> >
> > rewording: "Generic operations on filters"
> OK.
> > Could you elaborate on "generic"? What would mean "specific"?
> >
> OK, will add more description.
Generic operations means: the operations filter usually have, like add/delete/set ...
Specific means: different filter type may have different attributes, for example the filter's input set. The Specific stuffs are contained in the structure definition. Structure definition is not included in this patch. It need to be added in rte_eth_ctrl.h header file by owner who contributes to each kind of filter.
>
> > > +enum rte_filter_op {
> > > + RTE_ETH_FILTER_OP_NONE = 0,
> > > + /**< used to check whether the type filter is supported */
> > > + RTE_ETH_FILTER_OP_ADD, /**< add filter entry */
> > > + RTE_ETH_FILTER_OP_UPDATE, /**< update filter entry */
> > > + RTE_ETH_FILTER_OP_DELETE, /**< delete filter entry */
> > > + RTE_ETH_FILTER_OP_FLUSH, /**< flush all entries */
> > > + RTE_ETH_FILTER_OP_GET, /**< get filter entry */
> > > + RTE_ETH_FILTER_OP_SET, /**< configurations */
> > > + RTE_ETH_FILTER_OP_GET_INFO,
> >
> > Could we remove "OP", except for OP_NONE and OP_MAX?
> >
> Fine, ADD/UPDATE/... is operation definitely, OP may be redundant.
>
> > > + /**< get information of filter, such as status or statistics */
> > > + RTE_ETH_FILTER_OP_MAX,
> > > +};
> >
> > > +int
> > > +rte_eth_dev_filter_supported(uint8_t port_id, enum rte_filter_type
> > > +filter_type)
> >
> > This function is really important for compatibility. Good
> >
> > > +/**
> > > + * Take operations to assigned filter type on an Ethernet device.
> > > + * All the supported operations and filter types are defined in
> 'rte_eth_ctrl.h'.
> > > + *
> > > + * @param port_id
> > > + * The port identifier of the Ethernet device.
> > > + * @param filter_type
> > > + * filter type.
> > > + * @param filter_op
> > > + * The operation taken to assigned filter.
> >
> > Rewording: "Type of operation"
> >
> OK, will change.
>
> > > + * @param arg
> > > + * A pointer to arguments defined specifically for the operation.
> >
> > Actually, arg is specific to the filter type.
> > Could it be also specific to the operation. Maybe.
> > I think we will have to explicitly specify which operations can be
> > used with each structure (in its comments).
> >
> Yes, each owner who define structures here need to point out the specific
> filter type and operation in its comments.
>
> > > + * @return
> > > + * - (0) if successful.
> > > + * - (-ENOTSUP) if hardware doesn't support.
> > > + * - (-ENODEV) if *port_id* invalid.
> > > + * - others depends on the specific operations implementation.
> > > + */
> > > +int rte_eth_dev_filter_ctrl(uint8_t port_id, enum rte_filter_type
> filter_type,
> > > + enum rte_filter_op filter_op, void *arg);
> >
> > Could we add rx in the name? rte_eth_dev_rx_filter_ctrl If you agree
> > with this naming, it should be added in several other places.
> >
> We name it as rte_eth_dev_rx_filter_ctrl before. But we have no Idea
> whether we have tx_filter, or even have in future, we can share the API.
> So decided to name it as rte_eth_dev_filter_ctrl to make the name brief.
>
> > This API is quite simple (which is a good thing).
> > Let's see how it fits when integrating filtering features.
> > If something appears to be wrongly designed when integrating a feature
> > or when implementing it in a driver, feel free to fix the API.
> >
> We think so too.
>
> > Thanks
> > --
> > Thomas
> Thanks
> Jingjing
next prev parent reply other threads:[~2014-10-20 3:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 23:29 Jingjing Wu
2014-10-17 1:16 ` Zhang, Helin
2014-10-17 9:07 ` Thomas Monjalon
2014-10-17 9:17 ` Richardson, Bruce
2014-10-17 16:01 ` Wu, Jingjing
2014-10-20 3:38 ` Wu, Jingjing [this message]
2014-10-20 1:09 ` Liu, Jijiang
2014-10-20 5:40 ` [dpdk-dev] [PATCH v2 0/2] " Jingjing Wu
2014-10-20 5:40 ` [dpdk-dev] [PATCH v2 1/2] librte_ether: " Jingjing Wu
2014-10-20 5:40 ` [dpdk-dev] [PATCH v2 2/2] i40e: define filter_ctrl ops in i40e driver Jingjing Wu
2014-10-20 22:04 ` [dpdk-dev] [PATCH v2 0/2] new filter APIs definition Thomas Monjalon
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=9BB6961774997848B5B42BEC655768F8B1BFD9@SHSMSX104.ccr.corp.intel.com \
--to=jingjing.wu@intel.com \
--cc=dev@dpdk.org \
--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).