Yes, implementation and tests are needed before the general release. Should we postpone the general release until those are there? Does api-next have to have all implemented before merge to master? A new API definition does not break anything before someone tries to use it.
-Petri From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Mike Holmes Sent: Friday, April 24, 2015 8:12 PM To: Bill Fischofer Cc: lng-odp; Savolainen, Petri (Nokia - FI/Espoo) Subject: Re: [lng-odp] [API-NEXT PATCH v2] timer: Add missing platform handles to u64 conversion functions We specifically need the packet parsing switch and metadata for odp-dpdk to perform well so there is a need driving those for 1.1.0. I think we should strive to have tests and an implementation in before we merge any new API. I wonder how we specify who has the correct implementation unless that reference is present and agreed to first. In some cases I agree it should be obvious, but if so then some one with an interest should find it fairly easily to implement for linux-generic as well to speed its move to main line. Given that api-next follows mainline, implementations can start work with an API in its expected final form before the complete reference is in place without sacrificing anything. On Fri, Apr 24, 2015 at 8:00 AM, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com<mailto:petri.savolai...@nokia.com>> wrote: Also packet_user_area (metadata) and my pktio API changes are missing implementation. The delta between API 1.0 and 1.1 is pretty slim if those are left out also. -Petri From: ext Mike Holmes [mailto:mike.hol...@linaro.org<mailto:mike.hol...@linaro.org>] Sent: Friday, April 24, 2015 3:45 PM To: Savolainen, Petri (Nokia - FI/Espoo) Cc: Jerin Jacob; lng-odp Subject: Re: [lng-odp] [API-NEXT PATCH v2] timer: Add missing platform handles to u64 conversion functions On 24 April 2015 at 08:31, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com<mailto:petri.savolai...@nokia.com>> wrote: These are trivial enough to get into v1.1. I was thinking that we freeze the v1.1 API next week, and then work on the missing implementation/validation code before labeling the official 1.1.0 release . 1.1 is fine I assumed there would not be an implementation in time. If it is simple that is good, but we still need to identify some one to do the work. To be in for 1.1 which freezes on Wednesday we need an implementation to already be in api-next by Wednesday so that CI runs the tests. Is there any strong reason to hold up 1.1.0 for this ? If it is critical we can hold 1.1 for a few days assuming the work is about to land, but why not add it to 1.2.0 and release that early with the next crop of work and keep an even pace to development ? -Petri From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org>] On Behalf Of ext Mike Holmes Sent: Friday, April 24, 2015 2:55 PM To: Jerin Jacob Cc: lng-odp Subject: Re: [lng-odp] [API-NEXT PATCH v2] timer: Add missing platform handles to u64 conversion functions Hi Jerin Before this is merged with mainline I think we should have a linux-generic implementation and a test case for it. Do you have the cycles to add those to api-next so that this can be part of 1.2.0 ? I think tentatively that 1.2.0 will be in August at this point, although if we can start gathering more complete new API work in api-next there is no reason to wait that long. Mike On 24 April 2015 at 05:13, Jerin Jacob <jerin.ja...@caviumnetworks.com<mailto:jerin.ja...@caviumnetworks.com>> wrote: On Fri, Apr 24, 2015 at 11:46:53AM +0300, Maxim Uvarov wrote: > Hi Jerin, > > you you only removed RFC and Petri added sign-off to that patch you should > include it to patch without rfc. > > also "v1..v2..." should go after --- line in patch. In that case git am just > skips that comment. Thanks for pointing it out. > > Patch merged to api-next. > > Thanks, > Maxim. > > On 04/24/15 09:14, Jerin Jacob wrote: > >On Mon, Apr 20, 2015 at 04:22:15PM +0530, Jerin Jacob wrote: > > > >ping > > > >>v1..v2 Removed RFC > >> > >> > >>Signed-off-by: Jerin Jacob > >><jerin.ja...@caviumnetworks.com<mailto:jerin.ja...@caviumnetworks.com>> > >>--- > >> include/odp/api/timer.h | 39 +++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 39 insertions(+) > >> > >>diff --git a/include/odp/api/timer.h b/include/odp/api/timer.h > >>index 0dc9415..435c004 100644 > >>--- a/include/odp/api/timer.h > >>+++ b/include/odp/api/timer.h > >>@@ -366,6 +366,45 @@ odp_timeout_t odp_timeout_alloc(odp_pool_t pool); > >> void odp_timeout_free(odp_timeout_t tmo); > >> /** > >>+ * Get printable value for an odp_timer_pool_t > >>+ * > >>+ * @param hdl odp_timer_pool_t handle to be printed > >>+ * @return uint64_t value that can be used to print/display this > >>+ * handle > >>+ * > >>+ * @note This routine is intended to be used for diagnostic purposes > >>+ * to enable applications to generate a printable value that represents > >>+ * an odp_timer_pool_t handle. > >>+ */ > >>+uint64_t odp_timer_pool_to_u64(odp_timer_pool_t hdl); > >>+ > >>+/** > >>+ * Get printable value for an odp_timer_t > >>+ * > >>+ * @param hdl odp_timer_t handle to be printed > >>+ * @return uint64_t value that can be used to print/display this > >>+ * handle > >>+ * > >>+ * @note This routine is intended to be used for diagnostic purposes > >>+ * to enable applications to generate a printable value that represents > >>+ * an odp_timer_t handle. > >>+ */ > >>+uint64_t odp_timer_to_u64(odp_timer_t hdl); > >>+ > >>+/** > >>+ * Get printable value for an odp_timeout_t > >>+ * > >>+ * @param hdl odp_timeout_t handle to be printed > >>+ * @return uint64_t value that can be used to print/display this > >>+ * handle > >>+ * > >>+ * @note This routine is intended to be used for diagnostic purposes > >>+ * to enable applications to generate a printable value that represents > >>+ * an odp_timeout_t handle. > >>+ */ > >>+uint64_t odp_timeout_to_u64(odp_timeout_t hdl); > >>+ > >>+/** > >> * @} > >> */ > >>-- > >>2.1.0 > >> > >_______________________________________________ > >lng-odp mailing list > >lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > >https://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/lng-odp -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/lng-odp -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
