On 21 April 2015 at 22:51, Bill Fischofer <bill.fischo...@linaro.org> wrote:
> We discussed this during today's ODP public call. Petri has a proposed > set of API extensions to pktio to allow the application to tell the > implementation what it needs in terms of parsing. While this sounds > reasonable, my concern is that the application may not know as much as it > things it knows, especially as it evolves. Another approach is to use > "lazy evaluation" in the implementations so that packets are parsed on > demand when specific parse results are queried. This can be done at > various levels of granularity and sophistication depending on how the > implementation is structured. For linux-generic, it might be sufficient to > call _odp_packet_parse() on first call to an odp_packet_flags API. This > would seem to address OVS's immediate problem since it never calls these > routines since it does its own parsing and hence ODP wouldn't duplicate > this result. Over time OVS could switch to using the ODP parse results and > take advantages of HW parsing on those platforms that provide it > I don't know where we are today but I think this proposal makes a lot of sense. Simple to use, robust, will handle unanticipated changes in the application. And last but not least, actually solves the current problem we have with OVS. With the fine-grained parsing API, what happens if an application later asks for something which it did not specify when creating the pktio instance? Is this just undefined behaviour? > > On Wed, Apr 15, 2015 at 9:40 AM, Zoltan Kiss <zoltan.k...@linaro.org> > wrote: > >> >> >> On 14/04/15 20:04, Ola Liljedahl wrote: >> >>> On 14 April 2015 at 19:21, Zoltan Kiss <zoltan.k...@linaro.org >>> <mailto:zoltan.k...@linaro.org>> wrote: >>> >>> >>> >>> On 13/04/15 22:38, Ola Liljedahl wrote: >>> >>> On 8 April 2015 at 19:02, Zoltan Kiss <zoltan.k...@linaro.org >>> <mailto:zoltan.k...@linaro.org> >>> <mailto:zoltan.k...@linaro.org >>> <mailto:zoltan.k...@linaro.org>__>> wrote: >>> >>> Hi, >>> >>> OVS has a major performance issue with pktio at the moment: >>> pktio >>> always does parsing, but OVS does it for itself as well, >>> and it is >>> quite deeply woven into its code, so we can't easily modify >>> it to >>> use the ODP parsed data. Also, not every platform >>> accelerate that >>> (e.g. DPDK), at the moment it would make more sense to make >>> parsing >>> optional for pktio, so an application can opt not to do it. >>> I can see two options now to define the API: >>> - odp_pktio_open get a new bool parameter for this purpose >>> - we create a new odp_pktio_enable/disable_parse function >>> pair for >>> this purpose >>> >>> Is the result of the ODP packet parsing somehow used? >>> >>> No, but OVS might start use it in the future >>> >>> I wasn't thinking of whether some application is using the >>> classification functionality. Rather if no classification rules are >>> defined by the application, is the result of the parsing and >>> classification still somehow used internally? >>> >> >> Yes, in case of OVS probably we wouldn't need classification (at least >> not in the foreseeable future), but we would need parsing. >> >> If not, why not just skip >> >>> performing the classification if the results are not used? (i.e. a lazy >>> evaluation scheme). There should be no need for any big on/off switch >>> for classification. >>> >>> >>> >>> I would assume >>> >>> that OVS-ODP does not set up any classification rules so all >>> packets go >>> to some default destination anyway (some pktio input queue). >>> >>> OVS wouldn't just use the parsed data for QoS, but e.g. to create a >>> flow entry. I don't think the use of classification can decided >>> whether you need parsing or not. >>> >>> Can't the >>> >>> ODP implementation then bypass the classification stage if it can >>> understand (and it should be able to) that classification does >>> not >>> change the behavior? >>> >>> I would rather not invent explicit configurations when the >>> implementation should be able to deduce the best behavior based >>> on the >>> configuration provided by the user. >>> >>> >>> Any opinions about these options? >>> >>> Regards, >>> >>> Zoli >>> ___________________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >>> <mailto:lng-odp@lists.linaro.__org >>> <mailto:lng-odp@lists.linaro.org>> >>> https://lists.linaro.org/____mailman/listinfo/lng-odp >>> <https://lists.linaro.org/__mailman/listinfo/lng-odp> >>> <https://lists.linaro.org/__mailman/listinfo/lng-odp >>> <https://lists.linaro.org/mailman/listinfo/lng-odp>> >>> >>> >>> >>> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
