Yes, we'd be very interested in discussing this with you. We're having our weekly ODP call in less than an hour. Perhaps you can join us there. Also, will you be attending the LCU conference next month? We do plan to have ODP v2.0 planning discussions there and it sounds like you'd have good input to that.
Bill On Tue, Aug 26, 2014 at 8:53 AM, Gilad Ben Yossef <[email protected]> wrote: > Hi Bill, > Thank you very much for you feedback. > > From: Bill Fischofer [mailto:[email protected]] > > Sent: Tuesday, August 26, 2014 2:47 PM > > To: Taras Kondratiuk > > Cc: Gilad Ben Yossef; lng-odp-forward > > Subject: Re: [lng-odp] [ARCH DESIGN] Last call--Buffer Mgmt Design > > [SNIP] > > Gilad, the whole idea behind direct application access to buffer > contents is for exception paths and is expected to be infrequent. > OK, I guess that this was the part I was missing about the architecture. > So if I got you right an application using ODP which accesses a packet > buffer segment (by directly addressing it) for each frame not for debug > purposes is doing something outside the scope of the ODP design, right? > > > For normal operation, the expectation is that the classifier will parse > and abstract the relevant information from that packet into meta data that > the application can access directly since at line rate the application > doesn't have the bandwidth to parse packets itself. > Well, one person line rate is another person slow path... :-) > Certainly not trying to argue here, but so I make sure I understand > correctly - > I see the IPsec application example just submitted has the following > snippet: > +static inline > +int locate_ipsec_headers(odp_ipv4hdr_t *ip, > + odp_ahhdr_t **ah_p, > + odp_esphdr_t **esp_p) > +{ > + uint8_t *in = ipv4_data_p(ip); > + odp_ahhdr_t *ah = NULL; > + odp_esphdr_t *esp = NULL; > + > + if (ODP_IPPROTO_AH == ip->proto) { > + ah = (odp_ahhdr_t *)in; > + in += ((ah)->ah_len + 2) * 4; > + if (ODP_IPPROTO_ESP == ah->next_header) { > + esp = (odp_esphdr_t *)in; > + in += sizeof(odp_esphdr_t); > + } > + } else if (ODP_IPPROTO_ESP == ip->proto) { > + esp = (odp_esphdr_t *)in; > + in += sizeof(odp_esphdr_t); > + } > + > + *ah_p = ah; > + *esp_p = esp; > + return in - (ipv4_data_p(ip)); > +} > It looks to me the application is parsing the IPsec header of the packet, > which I expect to happen per frame. Is this a case of a bad example or did > I miss something again? > > So the idea behind these calls is to expose a minimal set of APIs that > can allow the application to see the raw packet data in a controlled > manner. It's up to the implementation to decide whether that's done via > direct addressability or via some mapping function, but the releases are > implicit and handled by the implementation as Taras noted. > OK, would that mean that for each new protocol one wishes to support one > would have to add support for it for each classifier implementation of each > platform of ODP? > Also, if one wishes to write an ODP application that takes every 2 bytes > of frame payload data of the first 64 bytes and adds them (just for kicks), > one does not have any ODP sanctioned way to do it at wire speed, even if > the platforms that support ODP can? > Again, I'm not trying to hackle. If ODP rules says "accessing packet data > by addressing it is a slow path operation" I'm perfectly fine with that, as > long as application writer targeting ODP don't assume that it is otherwise. > Just to give a little bit of context: the platform I'm targeting (EZchip > NPS-400) allows accessing packet data in software for each packets at 600 > Mfps and 400 Gbps. This is why I loathe to say "buffer data access API in > ODP is slow path only, no point in fussing over making it efficient on my > implementation" only to later discover application developers "abuse" said > APIs to parse, classify and modify each packet. > Hmm.. would you guys consider accepting a separate explicit and optional > API for accessing packet frame data that works at wire speeds, if the > platform supports it? > Many thanks, > Gilad Ben-Yossef > Software Architect > EZchip Technologies Ltd. > 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel > Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 > Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 > Email: [email protected], Web: http://www.ezchip.com > > "Ethernet always wins." > — Andy Bechtolsheim >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
