Wenzhou, thanks for note. > -----Original Message----- > From: Lu, Wenzhuo > Sent: Friday, January 20, 2017 10:15 AM > To: Adrien Mazarguil <adrien.mazarg...@6wind.com>; Thomas Monjalon > <thomas.monja...@6wind.com> > Cc: Liu, Yong <yong....@intel.com>; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] doc: announce ABI change for cloud filter > > Hi Adrien, Thomas, Yong, > > > -----Original Message----- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil > > Sent: Friday, January 20, 2017 2:46 AM > > To: Thomas Monjalon > > Cc: Liu, Yong; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cloud > > filter > > > > On Thu, Jan 19, 2017 at 10:06:34AM +0100, Thomas Monjalon wrote: > > > 2017-01-19 13:34, Yong Liu: > > > > +* ABI changes are planned for 17.05: structure > > > > +``rte_eth_tunnel_filter_conf`` > > > > + will be extended with a new member ``vf_id`` in order to enable > > > > +cloud filter > > > > + on VF device. > > > > > > I think we should stop rely on this API, and migrate to rte_flow instead. > > > Adrien any thought? > > > > I'm all for using rte_flow in any case. I've already documented an > > approach to convert TUNNEL filter rules to rte_flow rules [1], > > although it may be incomplete due to my limited experience with this > > filter type. We already know several tunnel item types must be added > > (currently only VXLAN is defined). > > > > I understand ixgbe/i40e currently map rte_flow on top of the legacy > > framework, therefore extending this structure might still be needed in > > the meantime. Not sure we should prevent this change as long as such > > rules can be configured through rte_flow as well. > > > > [1] > > http://dpdk.org/doc/guides/prog_guide/rte_flow.html#tunnel-to-eth-ipv4 > > - > > ipv6-vxlan-or-other-queue > The problem is we haven't finished transferring all the functions from the > regular > filters to the generic filters. > For example, igb, fm10k and enic haven't support generic filters yet. Ixgbe > and > i40e have supported the basic functions, but some advance features are not > transferred to generic filters yet. > Seems it's not the time to remove the regular filters. Yong, I suggest to > support > both generic filter and regular filter in parallel. > So, we need to announce ABI change for the regular filter, until someday we > remove the regular filter API.
I will enable VF support both in generic filter and original cloud filter API. So I think we still need ABI announcement for structure modification. > > > > > -- > > Adrien Mazarguil > > 6WIND
