We've stipulated that (for ODP v1.0 at least) that the initial packet segment is large enough to contain a reasonable amount of headroom + the packet headers.
I'd be interested in hearing if any implementations have problems doing this. Bill On Sun, Nov 9, 2014 at 3:00 PM, Ola Liljedahl <[email protected]> wrote: > On 7 November 2014 14:07, Bill Fischofer <[email protected]> > wrote: > > In working through the packet implementation in linux-generic, it seems > that > > headroom serves two purposes and my thought is to simply document this > > officially and I'd like to get thoughts on this. > > > > Headroom permits applications to reserve buffer space for additional > headers > > but it naturally also can serve to align packet frames. For example, > with > > the standard Ethernet header being 14 bytes it is often desirable that > > Ethernet frames are offset by 2 bytes from a word boundary so that the > > following Layer 3 header (typically IPv4 or IPv6) is word-aligned for > easy > > addressability. > > > > The proposal is that we simply document the intended use of the buffer > pool > > headroom specification for this purpose. Buffers within buffer pools > will > > be naturally aligned (cache alignment is RECOMMENDED) and based on this > the > > application can set a headroom to control both expansion as well as the > > alignment it wants to see for packets based on its knowledge of the > > protocols it will be handling for packets stored in that buffer pool. > > > > So the call odp_buffer_pool_set_headroom(pool,hr+2); is a natural means > of > > getting Ethernet packets aligned for header addressing purposes in > addition > > to reserving some number of bytes for expansion. > Is there any requirement that the frame actually starts directly after > the specified headroom? Or could an implementation pad an Ethernet > frame (in order to make the following IP addresses word aligned) even > if the user hadn't specified any such headroom? > > Ethernet MAC's may have limitations and can not start the received > frame at any offset (I have seen this in the past). So padding might > be added anyway regardless if the user specified that +2. Some > applications might not be smart enough to do this (many architectures > allow unaligned word access anyway with no or little penalty) and > could experience issues if ODP suddenly behaves in an unexpected way. > What can the application expect? > > > > > Thoughts on this? > It's a good idea. > > > > > Bill > > > > _______________________________________________ > > lng-odp mailing list > > [email protected] > > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
