Hi Bill, I’m going to send out a diff (not pasting it here due to Microsquish surely mucking it up) that I am using to make progress on Cisco DP. Your points are valid, I’m just trying to make something happen in the next couple weeks.
From: Bill Fischofer [mailto:[email protected]] Sent: Tuesday, August 19, 2014 12:36 PM To: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Cc: Robbie King (robking) Subject: Re: ODP packet API question... Adding the ODP list as this is of general interest. I agree that headroom is a buffer-pool attribute for packet use. odp_cos_set_headroom() was defined as a convenience in establishing this as part of classification setup. Implementations are free to impose restrictions on the use of features like headroom. For example, implementations are free to round up application-specified values to other values for whatever reason, or to have a first-call-wins policy for the case of many-to-one CoS-to-BP maps if they can't vary HR size on a per-CoS basis. The point is that things like headroom are fundamentally advisory in nature that tell the underlying implementation what the application may do as an aid to optimizing the behavior of subsequent API calls. We shouldn't assume that an API defines implementation behavior as there is always room for invention in how specific APIs are implemented on different platforms. In the case of headroom, while it may seem natural to assume implementing this involves reserving buffer prefix space, some implementations that have efficient segmentation support in HW may instead choose to do this by segment reservation or other HW gather processing such that prepended headers are seamlessly streamed during subsequent transmission. You actually need something more akin to this to do efficient implementation of things like large segment offload processing where a packet is automatically broken up during transmission into MTU-sized pieces with headers being replicated and finalized for each transmitted segment, or for transparent tunneling where tunnel headers dynamically encapsulate packets being transmitted through them. To capture the essence of this sort of processing you probably want to have the notion of header templates that can be instantiated for a given flow as part of packet assembly under HW rather than explicit application control. Bill On Tue, Aug 19, 2014 at 7:53 AM, Savolainen, Petri (NSN - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: Hi, It’s unlikely that HW can support per CoS class headrooms. Also I don’t think application needs such granularity. It could be either per pool or per packet io interface configuration. -Petri From: ext Bill Fischofer [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, August 18, 2014 6:05 PM To: Robbie King (robking) Cc: Savolainen, Petri (NSN - FI/Espoo) Subject: Re: ODP packet API question... The Classification API has an odp_cos_set_headroom() call that is designed to do this. We haven't translated that into a pktio-level call (yet), but I'd expect that's what the CoS stuff would need to do under the covers anyway. Bill On Mon, Aug 18, 2014 at 9:23 AM, Robbie King (robking) <[email protected]<mailto:[email protected]>> wrote: Was looking at current linux-generic packet IO code, looking for a way to influence the offset at which packets are stored in a buffer such that there is enough room for my DP code to prepend a header during processing. I didn’t see an API to influence that, and the socket code didn’t appear to support it other than to account for alignment. l2_hdr = ETHBUF_ALIGN(pkt_buf); /* Store eth buffer offset for pkt buffers from this pool */ pkt_sock->frame_offset = (uintptr_t)l2_hdr - (uintptr_t)pkt_buf; Was hoping to be able to skew the starting offset by 16 bytes. Is that something that is going to be supported, or is the idea to prepend a buffer to the packet? Thanks Robbie
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
