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]<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]>
https://lists.linaro.org/mailman/listinfo/lng-odp

_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to