On 30/04/15 20:26, Mike Holmes wrote:
On 30 April 2015 at 08:16, Bill Fischofer <[email protected]
<mailto:[email protected]>> wrote:
You've articulated why we don't need API changes for this. Each
implementation is free to optimize its performance as it chooses
without impacting the public APIs. Such performance optimizations
would be expected to evolve as implementations mature. We did an
initial cut at SW parsing and we can improve that by introducing
basic lazy parsing support to accommodate apps that do their own
parsing. At some future point we may do something more
sophisticated as needs dictate. But none of this need impact other
implementations since there are no API impacts.
If we change ODP APIs then we impact every ODP implementation, so we
should only do that if there is a genuine application functional
need for the change. If it's simply a question of performance,
that's a negotiation between the application and the implementation
writer.
In this debate I'd hate to see us miss 1.1.0 next week, we have a real
use case, ODP-OVS needs to disable ODP parsing whilst we bootstrap that
work.
If Zoltan is sure that lazy can work and hence we dont need an API
change right now then I am not worried, but other wise I think we
should accept simple parsing on/off and revise things as we have a use case.
Yes, I think lazy evaluation should work for OVS. It calls
odp_packet_has_error() once but that should be removed.
Zoli
Mike
On Thu, Apr 30, 2015 at 3:34 AM, Savolainen, Petri (Nokia -
FI/Espoo) <[email protected]
<mailto:[email protected]>> wrote:
Lazy parsing is one (SW based) implementation. Another
implementation may use e.g. firmware (or microcode) downloaded
into the packet input HW in interface initialization phase. That
time the implementation can e.g. decide the trade-off between
parser features and HW resource usage. The accelerator would do
all the parsing, no lazy SW parsing needed … but implementation
would know what to download there.____
__ __
Also lazy parsing cannot guess what application is going to ask
and in which order (== when it’s optimal to stop SW parsing).
For example, application calls odp_packet_has_l2(): do you parse
to the end of protocol stack right there or not? You may gain
performance if you do and application asks more flags later on –
or you may have done all the work for nothing, because
application did not ask anything else after that.____
__ __
Things get more complicated when more protocols are added: mpls,
nvgre, l2tp, etc. If your HW/FW implementation can support
everything specified in ODP API - but not at the same time,
which ones you should leave out (for SW parsing)?____
__ __
-Petri____
__ __
__ __
*From:*ext Ola Liljedahl [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Wednesday, April 29, 2015 8:19 PM
*To:* Zoltan Kiss
*Cc:* Savolainen, Petri (Nokia - FI/Espoo);
[email protected] <mailto:[email protected]>
*Subject:* Re: [lng-odp] [PATCH API-NEXT 4/5] api: packet_io:
added parse mode____
__ __
On 29 April 2015 at 18:14, Zoltan Kiss <[email protected]
<mailto:[email protected]>> wrote:____
It doesn't apply to api-next. Anyway, I've sent an
implementation, see "[API-NEXT PATCH] packet: implement optional
parsing". But if we go with Ola's idea, it won't be needed.____
Actually Bill's idea.____
__ __
If parsing is made lazy, where do you have to check whether to
actually perform the parsing? Hopefully we don't need a check in
every odp_packet_has_xxx() call. If the application is using the
odp_packet_flags.h API, is there some call which always will be
called (and called first) which can trigger the parsing? E.g.
odp_packet_has_error() could check whether parsing has been done
and if not do the parsing. Other calls may not have to perform
the check. Would such a design be robust enough?____
__ __
____
On 29/04/15 07:45, Savolainen, Petri (Nokia - FI/Espoo)
wrote:____
It's (v2) on the list (since last Thu):
[lng-odp] [API-NEXT PATCH v2 4/5] api: packet_io: added
parse mode
-Petri____
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp____
__ __
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
__
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
