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
