From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jijiang.liu@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 13CCC685D
for <dev@dpdk.org>; Mon, 20 Oct 2014 03:03:03 +0200 (CEST)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
by fmsmga101.fm.intel.com with ESMTP; 19 Oct 2014 18:11:12 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,749,1406617200"; d="scan'208";a="616959497"
Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82])
by fmsmga002.fm.intel.com with ESMTP; 19 Oct 2014 18:11:10 -0700
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS)
id 14.3.195.1; Mon, 20 Oct 2014 09:09:57 +0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS)
id 14.3.195.1; Mon, 20 Oct 2014 09:09:56 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
SHSMSX104.ccr.corp.intel.com ([169.254.5.174]) with mapi id 14.03.0195.001;
Mon, 20 Oct 2014 09:09:55 +0800
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>
Thread-Topic: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition
Thread-Index: AQHP6ZkXKn1OoRb6mkOVvyCdKKdQZJwzeleAgAS28CA=
Date: Mon, 20 Oct 2014 01:09:55 +0000
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D7ED77@SHSMSX101.ccr.corp.intel.com>
References: <1413502161-31403-1-git-send-email-jingjing.wu@intel.com>
<4027817.y7ZgbDzL4P@xps13>
In-Reply-To: <4027817.y7ZgbDzL4P@xps13>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] lib/librte_ether: new filter APIs definition
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Oct 2014 01:03:04 -0000
As to this API implementation in i40e, there are some common codes should b=
e included in this patch.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> 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 definit=
ion
>=20
> 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
>=20
> Why this name? I think we can reserve this file for filtering API.
> So rte_eth_rx_filter.h would be more appropriate.
>=20
> > +/**
> > + * All generic operations to filters
> > + */
>=20
> rewording: "Generic operations on filters"
> Could you elaborate on "generic"? What would mean "specific"?
>=20
> > +enum rte_filter_op {
> > + RTE_ETH_FILTER_OP_NONE =3D 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,
>=20
> Could we remove "OP", except for OP_NONE and OP_MAX?
>=20
> > + /**< get information of filter, such as status or statistics */
> > + RTE_ETH_FILTER_OP_MAX,
> > +};
>=20
> > +int
> > +rte_eth_dev_filter_supported(uint8_t port_id, enum rte_filter_type
> > +filter_type)
>=20
> This function is really important for compatibility. Good
>=20
> > +/**
> > + * 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.
>=20
> Rewording: "Type of operation"
>=20
> > + * @param arg
> > + * A pointer to arguments defined specifically for the operation.
>=20
> 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 w=
ith
> each structure (in its comments).
>=20
> > + * @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);
>=20
> 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.
>=20
> 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.
>=20
> Thanks
> --
> Thomas