On Thu, Oct 01, 2015 at 12:37:51PM +0000, Dumitrescu, Cristian wrote: > > > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > > Sent: Thursday, October 1, 2015 12:01 PM > > To: Singh, Jasvinder > > Cc: dev at 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 > >
