Patch “[lng-odp] [API-NEXT PATCH v3 4/5] api: packet_io: added parse mode” can be left out from the series for now, if need to have a timeout on parser/classifier configuration API. Lazy parsing is a workaround which won’t help to optimize HW/FW parsers.
All other patches are needed, though. -Petri From: ext Bill Fischofer [mailto:[email protected]] Sent: Tuesday, May 05, 2015 3:33 PM To: Zoltan Kiss Cc: Mike Holmes; [email protected]; Savolainen, Petri (Nokia - FI/Espoo) Subject: Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io: added parse mode 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 <[email protected]<mailto:[email protected]>> wrote: On 30/04/15 20:26, Mike Holmes wrote: On 30 April 2015 at 08:16, Bill Fischofer <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[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. 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) <[email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[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]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>>] *Sent:* Wednesday, April 29, 2015 8:19 PM *To:* Zoltan Kiss *Cc:* Savolainen, Petri (Nokia - FI/Espoo); [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[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]<mailto:[email protected]> <mailto:[email protected]<mailto:[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]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> https://lists.linaro.org/mailman/listinfo/lng-odp____ __ __ _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[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]<mailto:[email protected]> https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
