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
