On 30 April 2015 at 08:16, Bill Fischofer <[email protected]> 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. Mike > On Thu, Apr 30, 2015 at 3:34 AM, Savolainen, Petri (Nokia - FI/Espoo) < > [email protected]> 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:[email protected]] >> *Sent:* Wednesday, April 29, 2015 8:19 PM >> *To:* Zoltan Kiss >> *Cc:* Savolainen, Petri (Nokia - FI/Espoo); [email protected] >> *Subject:* Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added >> parse mode >> >> >> >> On 29 April 2015 at 18:14, Zoltan Kiss <[email protected]> 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 >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> > > _______________________________________________ > lng-odp mailing list > [email protected] > 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 [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
