Re: [dpdk-dev] [PATCH v2] ip_pipeline: add more functions to routing-pipeline

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Oct 01, 2015 at 12:37:51PM +0000, Dumitrescu, Cristian wrote:
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> > Sent: Thursday, October 1, 2015 12:01 PM
> > To: Singh, Jasvinder
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] ip_pipeline: add more functions to
> > routing-pipeline
> > 
> > >
> > >  /*
> > > @@ -106,9 +164,7 @@ struct pipeline_routing_route_add_msg_req {
> > >  	struct pipeline_routing_route_key key;
> > >
> > >  	/* data */
> > > -	uint32_t flags;
> > > -	uint32_t port_id; /* Output port ID */
> > > -	uint32_t ip; /* Next hop IP address (only valid for remote routes) */
> > > +	struct pipeline_routing_route_data data;
> > >  };
> > >
> > 
> > The example that you modifying appears to directly set the structure fields
> > that
> > you removing above.  As such these appear to be ABI breaking changes and
> > need to
> > go through the ABI process
> > 
> > Neil
> 
> Hi Neil,
> 
> This patch only changes application code (in DPDK examples/ip_pipeline folder), it does not change any library code (in DPDK lib folder). There is no ABI versioning required for the example applications, so I don't think the ABI restrictions are applicable here.
> 
> The pipelines in the ip_pipeline application are provided only as examples to encourage people to create their own pipelines, and their implementation is evolving as new features are added.  They are intended to support only a limited set of protocols and features; for example, in this case of the routing pipeline, there is no intention to have them support an exhaustive list of routing protocols (as this would be virtually impossible). Therefore, there is no plan to standardize them and make them library code, where the API/ABI preservation is required.
> 
> The code where we are committed to keep the API compatibility and apply the ABI change process rigorously is the library code (e.g. librte_port, librte_table, librte_pipeline) and we are consistently doing this.
> 
> Thank you for your comment!
> 
Yup, youre right, my bad, I looked at the header file and thought it was part of
one of the libraries

Neil

> Regards,
> Cristian
> 
>