Petri has proposed that results are undefined if you lie. On Tue, Apr 28, 2015 at 8:47 AM, Ola Liljedahl <ola.liljed...@linaro.org> wrote:
> 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
