From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <beilei.xing@intel.com>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
 by dpdk.org (Postfix) with ESMTP id BFAC520F
 for <dev@dpdk.org>; Wed, 28 Dec 2016 08:29:25 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by fmsmga104.fm.intel.com with ESMTP; 27 Dec 2016 23:29:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,421,1477983600"; d="scan'208";a="23603420"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
 by orsmga002.jf.intel.com with ESMTP; 27 Dec 2016 23:29:12 -0800
Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by
 fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Tue, 27 Dec 2016 23:29:11 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
 fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Tue, 27 Dec 2016 23:29:11 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.177]) by
 SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002;
 Wed, 28 Dec 2016 15:29:09 +0800
From: "Xing, Beilei" <beilei.xing@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>, "Zhang, Helin"
 <helin.zhang@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH v2 12/17] net/i40e: destroy ethertype filter
Thread-Index: AQHSYLqys9LJ8yEKwUeRW/fcsczZa6Ec9hnA
Date: Wed, 28 Dec 2016 07:29:09 +0000
Message-ID: <94479800C636CB44BD422CB454846E013158C018@SHSMSX101.ccr.corp.intel.com>
References: <1480679625-4157-1-git-send-email-beilei.xing@intel.com>
 <1482819984-14120-1-git-send-email-beilei.xing@intel.com>
 <1482819984-14120-13-git-send-email-beilei.xing@intel.com>
 <9BB6961774997848B5B42BEC655768F810CC00FA@SHSMSX103.ccr.corp.intel.com>
In-Reply-To: <9BB6961774997848B5B42BEC655768F810CC00FA@SHSMSX103.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [dpdk-dev] [PATCH v2 12/17] net/i40e: destroy ethertype filter
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <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: Wed, 28 Dec 2016 07:29:26 -0000



> -----Original Message-----
> From: Wu, Jingjing
> Sent: Wednesday, December 28, 2016 11:30 AM
> To: Xing, Beilei <beilei.xing@intel.com>; Zhang, Helin
> <helin.zhang@intel.com>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2 12/17] net/i40e: destroy ethertype filter
>=20
> >
> >  const struct rte_flow_ops i40e_flow_ops =3D {
> >  	.validate =3D i40e_flow_validate,
> > @@ -1492,11 +1495,16 @@ i40e_flow_destroy(__rte_unused struct
> > rte_eth_dev *dev,
> >  		  struct rte_flow *flow,
> >  		  struct rte_flow_error *error)
> >  {
> > +	struct i40e_pf *pf =3D I40E_DEV_PRIVATE_TO_PF(dev->data-
> > >dev_private);
> >  	struct i40e_flow *pmd_flow =3D (struct i40e_flow *)flow;
> >  	enum rte_filter_type filter_type =3D pmd_flow->filter_type;
> >  	int ret;
> >
> >  	switch (filter_type) {
> > +	case RTE_ETH_FILTER_ETHERTYPE:
> > +		ret =3D i40e_dev_destroy_ethertype_filter(pf,
> > +				(struct i40e_ethertype_filter *)pmd_flow-
> >rule);
> > +		break;
> >  	default:
> >  		PMD_DRV_LOG(WARNING, "Filter type (%d) not supported",
> >  			    filter_type);
> > @@ -1504,10 +1512,49 @@ i40e_flow_destroy(__rte_unused struct
> > rte_eth_dev *dev,
> >  		break;
> >  	}
> >
> > -	if (ret)
> > +	if (!ret) {
> > +		TAILQ_REMOVE(&pf->flow_list, pmd_flow, node);
> > +		free(pmd_flow);
> Should it be freed inside the function? Is the API definition like that?

Yes, since API or rte won't free the flow allocated by PMD. Please refer to=
 the attached mail.