I'm currently playing around with this and as usual there's no free lunch. The only way to know whether you need to parse is to check a bit, which at least doubles the cost of the odp_packet_has_xxx() calls since normally they are just returning a bit. So now the logic for each of these is:
if (parsing is needed) do the parse return the parse/flag we need. The only way to really make this efficient is to call ODP APIs indirectly via a jump vector that can be dynamically patched. So these routines all start out as "do the parse first" and as part of that parse the jump vector is updated so that the next call bypasses the do-I-need-to-parse check. But that's tricky to do on many systems and can introduce race conditions if not done carefully. This is one of the reasons I think starting out with the big none/all switch is probably the way to go. If we can convert OVS to using ODP parsing then we can experiment with refining how parsing is done to achieve best performance. On Wed, Apr 29, 2015 at 12:19 PM, Ola Liljedahl <[email protected]> wrote: > 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
