On Tue, Aug 8, 2017 at 3:10 PM, Liron Himi <lir...@marvell.com> wrote:
> See comments inline in particular the change in RED > > > > *From:* Bill Fischofer [mailto:bill.fischo...@linaro.org] > *Sent:* Tuesday, August 08, 2017 22:57 > *To:* Liron Himi <lir...@marvell.com> > *Cc:* lng-odp@lists.linaro.org > *Subject:* Re: [EXT] Re: [lng-odp] Parser configuration > > > > > > > > On Tue, Aug 8, 2017 at 2:29 PM, Liron Himi <lir...@marvell.com> wrote: > > See comments inline > > > > Liron > > > > *From:* Bill Fischofer [mailto:bill.fischo...@linaro.org] > *Sent:* Tuesday, August 08, 2017 22:07 > *To:* Liron Himi <lir...@marvell.com> > *Cc:* lng-odp@lists.linaro.org > *Subject:* [EXT] Re: [lng-odp] Parser configuration > > > > External Email > ------------------------------ > > > > > > On Tue, Aug 8, 2017 at 1:43 PM, Liron Himi <lir...@marvell.com> wrote: > > Hi, > > 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 * > > I'd think you'd need to have something like this. But it's expected that most ODP implementations even for platforms that have HW acceleration will involve a combination of both SW and HW since ODP APIs won't match the native HW exactly. One of the goals of having a stable and rich ODP API set is that over time SoC HW will more directly support these APIs as the base of applications that make use of them grows. > > > > 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. > > > > > > > Regards, > Liron > > > > >
