On 14/04/15 20:04, Ola Liljedahl wrote:
On 14 April 2015 at 19:21, Zoltan Kiss <[email protected]
<mailto:[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]>
<mailto:[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?
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
[email protected] <mailto:[email protected]>
<mailto:[email protected].__org
<mailto:[email protected]>>
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
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp