A lazy parser only parses when the results of parsing are asked for by the application. So if the application never asks (as is the case for OVS today) then nothing gets called, so no overhead.
There is a certain amount of overhead imposed by lazy parsing for programs that do ask for parse results since the code needs to check whether or not parsing is needed. Nothing is completely free. I don't have a problem with the blanket all/none parse settings we've been discussed. My issue is trying to go beyond that to be too fancy. On Wed, Apr 29, 2015 at 11:50 AM, Zoltan Kiss <[email protected]> wrote: > > > On 29/04/15 16:41, Ola Liljedahl wrote: > >> On 29 April 2015 at 16:10, Bill Fischofer <[email protected] >> <mailto:[email protected]>> wrote: >> >> We need to be careful about trying to solve problems that haven't >> arisen yet. There are several interrelated issues here: >> >> 1. Parsing (and classification) in SW takes cycles. This should >> only be done once, not duplicated between the app and the ODP >> implementation, and ideally should only be done to the degree that >> the results are actually needed by the application. >> >> 2. The ultimate goal is for applications to make use of ODP's >> parsing/classification capabilities since these will be >> HW-accelerated on many platforms today, and on all platforms in the >> future. >> >> Therefore, any proposed changes to the API need to keep these two >> goals in mind. The goal is to help transition apps away from doing >> parsing/classification themselves, not to give increasingly complex >> (and increasingly irrelevant in a HW-accelerated world) advice to >> the implementation as to what they need. >> >> This is one of the reasons why none/all is a good starting point, >> since it solves our immediate need for legacy apps running on SW >> implementations. Those platforms that have zero-cost HW parsing can >> safely ignore a 'none' spec with no ill effect, while SW platforms >> will eliminate unwanted overhead. Beyond that, I believe simplest >> and most future-proof means of addressing the above goals is to >> explore lazy evaluation approaches to SW parsing in ODP. This >> involves no new APIs that would have only transitory utility and is >> transparent to the application. >> >> So we have a proposed solution which does not require any changes to the >> API. >> > What solution do you mean? I don't see any which lets the application > disabling parsing AND doesn't require API change. > > > Why don't we try out this solution and see where it gets us? > >> Changing the API (and making it more complicated, both to implement and >> to use) without having verified that this is the only solution is not a >> smart move. Keeping the architecture simple is an important goal (it >> will grow anyway but the role of an architect is to resist changes and >> propose alternative solutions using the existing mechanisms and API's). >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
