On 27 April 2015 at 11:03, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolai...@nokia.com> wrote:
> 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 > I do not see implementation patch. Only this api patch. Maxim. > > > *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> 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] > *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> 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] *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> > 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> > > >>--- > > >> 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 > > >https://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/lng-odp > _______________________________________________ > lng-odp mailing list > 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 > 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 > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp