See comments inline in particular the change in RED

From: Bill Fischofer []
Sent: Tuesday, August 08, 2017 22:57
To: Liron Himi <>
Subject: Re: [EXT] Re: [lng-odp] Parser configuration

On Tue, Aug 8, 2017 at 2:29 PM, Liron Himi 
<<>> wrote:
See comments inline


From: Bill Fischofer 
Sent: Tuesday, August 08, 2017 22:07
To: Liron Himi <<>>
Subject: [EXT] Re: [lng-odp] Parser configuration

External Email

On Tue, Aug 8, 2017 at 1:43 PM, Liron Himi 
<<>> wrote:

I have a query regarding the new parser configuration.
Let's say application set it to 'ODP_PKTIO_PARSER_LAYER_L2', does it means that 
the platform implementation must parse and recognize all eth-type that have ODP 
API such as ARP,VLAN, etc.? same for ICMP, etc for L3?

ODP defines the protocols it supports at a given layer and implementations that 
parse at that layer are expected to support those protocols. Implementations 
are free to parse deeper than requested, but must parse to at least the 
configured layer on a per-pktio basis. The parse results are accessed by the 
various odp_packet_has_xxx() APIs, and these are exercised by the pktio 
validation test suite.

However, while VLAN is a Layer 2 protocol, ARP is a Layer 3 protocol and ICMP 
is a Layer 4 protocol.

I'm asking it as I tried to run the parser validation tests and only the ones 
with ARP and ICMP are failing.
It seems that the validation tests expect from the platform implementation to 
flag it.

The validation test sets ODP_PKTIO_PARSER_LAYER_ALL and then tests individual 
packet types on a per-layer basis. Does your platform not parse ARP or ICMP?
[L.H.] Our platform implementation only support the protocols that are 
supported by our HW. We don’t do additional SW parsing as it will have 
performance penalty.

Does the HW signal whether it encountered protocols it didn't recognize? That 
would allow you to do supplemental SW parsing only in such cases, which would 
permit the current validation tests to pass without incurring extra overhead 
for the expected cases.
[L.H.] I need to check, but even if it is available I will need to surround it 
with ‘unlikely’ to reduce performance hit

Is that only validation test assumption or this is the real assumption and 
expectation from the platform?
Maybe it is good to extend the parser with supported protocol per layer in the 
capabilities. Same as we have for checksum support.

That might be an interesting addition, but may not buy much. The parser layer 
controls were added to allow applications to hint platforms that do SW parsing 
since in such platforms parsing to a depth that isn't needed by the application 
wastes cycles. Platforms that have HW parsers typically parse everything at 
line rate anyway, so these controls are effectively ignored.
[L.H.] Our HW currently do have HW parsing but not all protocols are identify 
by it. E.g. In L4 we only identify UDP and TCP.
So the above suggestion will allow us to communicate with the application on 
the supported protocols.
I think it is make sense that along with the supported parsing layer the 
platform implementation will also specific the supported protocols.
As probably some platform will need sw parsing to support all protocol, maybe 
application will also want to give a hint on the required protocols.
e.g. TCP application that only need TCP support and no other protocols.
In the future ODP may extend its protocols support, I guess that forcing the 
platform to support them even if require SW parsing is NOT a good idea.

The larger problem is that there are many protocols that ODP currently doesn't 
recognize and when you add to that application-specific shim layers, tunneling 
options, etc. it becomes clear that the current predefined protocol set is too 
restrictive and inflexible to meet application needs going forward. For this 
reason we'd like to explore integration with more advanced technologies like 
P4, which would permit the parser definitions to be offloaded from the ODP API 
specification and modularized.  Applications would then be free to define their 
own arbitrary packet formats, or to select from a library of predefined packet 
templates that cover these extended parsing needs while still being able to 
take advantage of HW-accelerated parsing.


Reply via email to