Given Zoltan's confirmation I would recommend that we defer the PktIO changes until we can have a more complete discussion of what would be useful/needed as a next-phase classification API (including specifying parse needs) and rely on lazy parsing in SW to meet the immediate needs for OVS performance enhancement.
On Tue, May 5, 2015 at 7:12 AM, Zoltan Kiss <zoltan.k...@linaro.org> wrote: > > > On 30/04/15 20:26, Mike Holmes wrote: > >> >> >> On 30 April 2015 at 08:16, Bill Fischofer <bill.fischo...@linaro.org >> <mailto:bill.fischo...@linaro.org>> wrote: >> >> You've articulated why we don't need API changes for this. Each >> implementation is free to optimize its performance as it chooses >> without impacting the public APIs. Such performance optimizations >> would be expected to evolve as implementations mature. We did an >> initial cut at SW parsing and we can improve that by introducing >> basic lazy parsing support to accommodate apps that do their own >> parsing. At some future point we may do something more >> sophisticated as needs dictate. But none of this need impact other >> implementations since there are no API impacts. >> >> If we change ODP APIs then we impact every ODP implementation, so we >> should only do that if there is a genuine application functional >> need for the change. If it's simply a question of performance, >> that's a negotiation between the application and the implementation >> writer. >> >> >> In this debate I'd hate to see us miss 1.1.0 next week, we have a real >> use case, ODP-OVS needs to disable ODP parsing whilst we bootstrap that >> work. >> >> If Zoltan is sure that lazy can work and hence we dont need an API >> change right now then I am not worried, but other wise I think we >> should accept simple parsing on/off and revise things as we have a use >> case. >> > > Yes, I think lazy evaluation should work for OVS. It calls > odp_packet_has_error() once but that should be removed. > > Zoli > > >> Mike >> >> >> On Thu, Apr 30, 2015 at 3:34 AM, Savolainen, Petri (Nokia - >> FI/Espoo) <petri.savolai...@nokia.com >> <mailto:petri.savolai...@nokia.com>> wrote: >> >> Lazy parsing is one (SW based) implementation. Another >> implementation may use e.g. firmware (or microcode) downloaded >> into the packet input HW in interface initialization phase. That >> time the implementation can e.g. decide the trade-off between >> parser features and HW resource usage. The accelerator would do >> all the parsing, no lazy SW parsing needed … but implementation >> would know what to download there.____ >> >> __ __ >> >> Also lazy parsing cannot guess what application is going to ask >> and in which order (== when it’s optimal to stop SW parsing). >> For example, application calls odp_packet_has_l2(): do you parse >> to the end of protocol stack right there or not? You may gain >> performance if you do and application asks more flags later on – >> or you may have done all the work for nothing, because >> application did not ask anything else after that.____ >> >> __ __ >> >> Things get more complicated when more protocols are added: mpls, >> nvgre, l2tp, etc. If your HW/FW implementation can support >> everything specified in ODP API - but not at the same time, >> which ones you should leave out (for SW parsing)?____ >> >> __ __ >> >> -Petri____ >> >> __ __ >> >> __ __ >> >> *From:*ext Ola Liljedahl [mailto:ola.liljed...@linaro.org >> <mailto:ola.liljed...@linaro.org>] >> *Sent:* Wednesday, April 29, 2015 8:19 PM >> *To:* Zoltan Kiss >> *Cc:* Savolainen, Petri (Nokia - FI/Espoo); >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> *Subject:* Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: >> added parse mode____ >> >> __ __ >> >> On 29 April 2015 at 18:14, Zoltan Kiss <zoltan.k...@linaro.org >> <mailto:zoltan.k...@linaro.org>> wrote:____ >> >> It doesn't apply to api-next. Anyway, I've sent an >> implementation, see "[API-NEXT PATCH] packet: implement optional >> parsing". But if we go with Ola's idea, it won't be needed.____ >> >> Actually Bill's idea.____ >> >> __ __ >> >> If parsing is made lazy, where do you have to check whether to >> actually perform the parsing? Hopefully we don't need a check in >> every odp_packet_has_xxx() call. If the application is using the >> odp_packet_flags.h API, is there some call which always will be >> called (and called first) which can trigger the parsing? E.g. >> odp_packet_has_error() could check whether parsing has been done >> and if not do the parsing. Other calls may not have to perform >> the check. Would such a design be robust enough?____ >> >> __ __ >> >> ____ >> >> >> On 29/04/15 07:45, Savolainen, Petri (Nokia - FI/Espoo) >> wrote:____ >> >> It's (v2) on the list (since last Thu): >> >> [lng-odp] [API-NEXT PATCH v2 4/5] api: packet_io: added >> parse mode >> >> >> -Petri____ >> >> _______________________________________________ >> 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 >> >> __ >> >> >> >> >> _______________________________________________ >> 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
