On 24 April 2015 at 10:14, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> The user metadata patch I submitted is complete. If you rename the APIs > you just need to also rename the implementations and then that will be > complete as well. > 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
