On 14 April 2015 at 19:21, Zoltan Kiss <[email protected]> wrote:
> > > On 13/04/15 22:38, Ola Liljedahl wrote: > >> On 8 April 2015 at 19:02, Zoltan Kiss <[email protected] >> <mailto:[email protected]>> 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? 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 >> [email protected] <mailto:[email protected]> >> https://lists.linaro.org/__mailman/listinfo/lng-odp >> <https://lists.linaro.org/mailman/listinfo/lng-odp> >> >> >>
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
