Hi Adrien Mazarguil, > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] > Sent: Tuesday, October 11, 2016 4:21 PM > To: Zhao1, Wei <wei.zhao1 at intel.com> > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC v2] Generic flow > director/filtering/classification > API > > Hi Wei, > > 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. */ }; > > Well I thought it made sharing flow RSS configuration with its counterpart in > struct rte_eth_conf easier (this pointer should even be const). Also, while > ABI breakage would still occur if rte_eth_rss_conf happened to be modified, > 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 completely > safe but I guess that would be somewhat overkill. > > Now considering this API was written without an initial implementation, all > structure definitions that do not make sense are still open to debate, we can > adjust them as needed. > > -- > Adrien Mazarguil > 6WIND
Your explanation seems very reasonable for me, structure pointer is an very experienced usage in this situation. Thank you!