[dpdk-dev] doc: announce ABI change for cloud filter

  Signed-off-by: Yong Liu <yong.liu@intel.com>
  

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?
  

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yong Liu
> Sent: Thursday, January 19, 2017 5:34 AM
> To: dev@dpdk.org
> Cc: Liu, Yong <yong.liu@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for cloud filter
> 
> Signed-off-by: Yong Liu <yong.liu@intel.com>

Acked-by: John McNamara <john.mcnamara@intel.com>
  

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
  

Hi Adrien, Thomas, Yong,

> -----Original Message-----
> From: dev [mailto:dev-bounces@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. 

> 
> --
> Adrien Mazarguil
> 6WIND
  

Wenzhou, thanks for note.

> -----Original Message-----
> From: Lu, Wenzhuo
> Sent: Friday, January 20, 2017 10:15 AM
> To: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Cc: Liu, Yong <yong.liu@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-bounces@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
  

2017-01-20 02:14, Lu, Wenzhuo:
> Hi Adrien, Thomas, Yong,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@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 disagree.
There is a new API framework (rte_flow) and we must focus on this transition.
It means we must stop any work on the legacy API.
  

On Fri, Jan 20, 2017 at 03:57:28PM +0100, Thomas Monjalon wrote:
> 2017-01-20 02:14, Lu, Wenzhuo:
> > Hi Adrien, Thomas, Yong,
> > 
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@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 disagree.
> There is a new API framework (rte_flow) and we must focus on this transition.
> It means we must stop any work on the legacy API.

I agree with Thomas here.