diff mbox

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

Message ID 1484804043-50156-1-git-send-email-yong.liu@intel.com (mailing list archive)
State Rejected, archived
Delegated to: Thomas Monjalon
Headers show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel compilation success Compilation OK

Commit Message

Liu, Yong Jan. 19, 2017, 5:34 a.m. UTC
Signed-off-by: Yong Liu <yong.liu@intel.com>

Comments

Thomas Monjalon Jan. 19, 2017, 9:06 a.m. UTC | #1
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?
Mcnamara, John Jan. 19, 2017, 5:39 p.m. UTC | #2
> -----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>
Adrien Mazarguil Jan. 19, 2017, 6:45 p.m. UTC | #3
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
Wenzhuo Lu Jan. 20, 2017, 2:14 a.m. UTC | #4
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
Liu, Yong Jan. 20, 2017, 2:18 a.m. UTC | #5
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
Thomas Monjalon Jan. 20, 2017, 2:57 p.m. UTC | #6
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.
Jerin Jacob Feb. 14, 2017, 3:19 a.m. UTC | #7
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.
diff mbox

Patch

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 755dc65..0defd02 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -62,3 +62,7 @@  Deprecation Notices
   PMDs that implement the latter.
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
+
+* 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.