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
