From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0570E376C for ; Wed, 12 Oct 2016 04:38:48 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 11 Oct 2016 19:38:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,332,1473145200"; d="scan'208";a="1063613248" Received: from kmsmsx154.gar.corp.intel.com ([172.21.73.14]) by orsmga002.jf.intel.com with ESMTP; 11 Oct 2016 19:38:46 -0700 Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.149]) by KMSMSX154.gar.corp.intel.com ([169.254.12.140]) with mapi id 14.03.0248.002; Wed, 12 Oct 2016 10:38:46 +0800 From: "Zhao1, Wei" To: Adrien Mazarguil CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification API Thread-Index: AdIi2dDqP9BHS9xsQjK03nj+YHXhnf//uBuA//6q7HCAApQZAP/+STpA Date: Wed, 12 Oct 2016 02:38:45 +0000 Message-ID: References: <20161010131927.GK17252@6wind.com> <20161011082116.GL17252@6wind.com> In-Reply-To: <20161011082116.GL17252@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjc1ZjVkMGYtM2NhNi00MTkwLWEyMjEtNjIxNWY0Yzk2MWFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Imgxa1hpOWsxR0ZPWDdlMEtVWmZOdlRwYkhyaXVvOFIxOStRdk0rQzFWZTg9In0= x-ctpclassification: CTP_IC x-originating-ip: [172.30.20.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 02:38:49 -0000 Hi Adrien Mazarguil, > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Tuesday, October 11, 2016 4:21 PM > To: Zhao1, Wei > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classifi= cation > API >=20 > Hi Wei, >=20 > On Tue, Oct 11, 2016 at 01:47:53AM +0000, Zhao1, Wei wrote: > > Hi Adrien Mazarguil, > > There is a struct rte_flow_action_rss in rte_flow.txt, the member > rss_conf is a pointer type, is there any convenience in using pointer? > > Why not using struct rte_eth_rss_conf rss_conf type, as > rte_flow_item_ipv4/ rte_flow_item_ipv6 struct member? > > > > Thank you. > > > > struct rte_flow_action_rss { > > struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */ > > uint16_t queues; /**< Number of entries in queue[]. */ > > uint16_t queue[]; /**< Queues indices to use. */ }; >=20 > Well I thought it made sharing flow RSS configuration with its counterpar= t in > struct rte_eth_conf easier (this pointer should even be const). Also, whi= le > ABI breakage would still occur if rte_eth_rss_conf happened to be modifie= d, > the impact on this API would be limited as it would not cause a change in > structure size. We'd ideally need some kind of version field to be comple= tely > safe but I guess that would be somewhat overkill. >=20 > Now considering this API was written without an initial implementation, a= ll > structure definitions that do not make sense are still open to debate, we= can > adjust them as needed. >=20 > -- > Adrien Mazarguil > 6WIND Your explanation seems very reasonable for me, structure pointer is an very= experienced usage in this situation. Thank you!