BTW, what complicates doing lazy evaluation is the existence of the various odp_packet_has_xxx_set() APIs we've defined. If you set a value you should be able to retrieve it without triggering parsing since you've taking control of that variable yourself. So each parse "bit" actually needs to be a "trit" to allow for true/false/unset states. Again, that doesn't come for free.
On Wed, Apr 29, 2015 at 12:01 PM, Ola Liljedahl <[email protected]> wrote: > On 29 April 2015 at 17:50, 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. >> > The implementation can defer the parsing until one of the packet_flags.h > functions is called. If these functions are not called, then parsing will > not be done for that packet. Lazy evaluation. > > Is the OVS code calling any function in packet_flags.h? Perhaps > odp_packet_has_error(). I assume this function doesn't necessarily have to > parse the packet content, just report any flags (e.g. FCS error, runt, > babble) from the HW (Ethernet MAC). All other error checks (e.g. IP header > checksum) would have to be done by the application, perhaps this is already > the case with OVS. > > > >> 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
