These are good questions. Answers inline. On Thu, Nov 17, 2016 at 10:52 AM, Joe Savage <joe.sav...@arm.com> wrote:
> > ODP specifies functional behavior of it's APIs. Implementations are free > to > > choose whatever techniques or other internals they wish to realize this > > behavior. So things like lazy/deferred/batched operations are entirely > > possible as long as the external semantics are matched. > > Sure, and that's really what I was asking: is there sufficient flexibility > in the defined behaviour of concat and split to allow for a zero-copy > implementation to exist in the context of fragmentation/reassembly? > > From your response I assume the answer is yes, but that wasn't necessarily > clear to me as an ODP newbie. Particularly, I'm unsure if implementations > are able to create packets with segment of differing lengths, as may be > useful in an efficient zero-copy software implementation. > ODP packets are opaque objects of type odp_packet_t that have observable behavior as defined by the ODP API specification. Packet structure is only observable on the part of applications only as a byproduct of requesting addressability to a packet. For this, ODP recognizes that implementations may store packets in one or more discontiguous segments of implementation-defined length. Applications may request minimum segment lengths at the time packet pools are created, but implementations are free to use larger lengths for internal reasons. Whenever a packet is made addressable (by returning a void * pointer to the offset in the packet that is requested) one of the return parameter is an integer length that tells the caller how many contiguously addressable bytes are available to it at the returned address. If the application wishes to address beyond that point, another API call is required to get addressability to the next segment. There is no requirement that segments be of any particular length, though zero-length segments, if they exist at all, are not visible via the ODP APIs. So the returned segment length will always be a minimum of 1 byte in length. This is discussed in the ODP User's Guide, which I recommend reading. > > > > odp-linux is designed to provide a simple and clear reference > > implementation of the ODP APIs. These are not necessarily optimized for > > performance. > > Sure, I totally appreciate that, but I'm more interested in the API in the > abstract here. What I'm trying to get at is whether split and concat were > designed with a particular use case in mind. If so, its not unreasonable to > think that implementations might optimise for this common use case, the > requirements of which may not match my desired behaviour for fragmentation > and reassembly. After all, it's not always the case that one size fits all, > and perhaps a disparity in requirements between seemingly similar packet > splitting or concatenation tasks could indicate that a new API would be > useful. > IP Fragment reassembly can be realized with these APIs. Packet references can also be used for this as individual fragments can be assembled as a series of compound references (at least in the current proposed definition of these APIs). However since these APIs have not yet been finalized pending confirmation that the major platforms that are implementing ODP are comfortable with these definitions. Part of the process of defining ODP APIs is we try to satisfy two parties: application writers, who want a robust and useful set of semantics, and platform implementers, who want to be sure that defined ODP APIs can be mapped to their platforms efficiently and can usefully exploit HW features found on those platforms. > > Not to say that I necessarily think doing this would be necessary here, but > just that I'm trying to better understand what you might expect a decidedly > "good" general implementation to do, and whether that would fit with my > desired behaviour for this task. > > > > The key difference between split/concat and references is that the latter > > imposes usage restrictions on the end-product while the former do not. So > > the "shared" portion of references should be treated as read/only by the > > application. > > Reading the proposal I completely agree that this is a key difference, but > as > per my point above regarding how the expected usage of APIs will guide the > behaviour of implementations, I think it's entirely possible that there > will > be other deep-rooted disparities between how implementations handle these > two seemingly similar concepts. As such, I'm just trying to figure out > whether — on the API level — you have an idea about what those differences > might be. And, indeed, how those differences might lead me to choosing to > use > concat over references (or visa versa) when writing my reassembly code. > As with most APIs, there is usually more than one combination of calls that can be used to accomplish the same objective. It's also possible that while all ODP implementations support all ODP APIs that there are relative performance differences between platforms such that one idiom may be more efficient than another on a given platform. For example, ODP allows packets to be addressed by byte offsets or logical segments. While offset addressing is considered the "preferred" set of APIs since it's simplest for applications, logical segment addressing is there because on some platforms this can be more efficiently realized than offset addressing. So it really depends on what the application is targeting. ODP is defining two main application "profiles": An embedded profile designed to provide optimal performance against a known target platform, and a "cloud" profile designed to provide optimal portability across a range of unknown target platforms in an NFV environment. The intent is to provide application writers with the tools to make the best tradeoffs for their needs while still maximizing portability and performance subject to these constraints.
