The implementation is always free to add to the user-requested amount as the application is specifying the minimum it needs. However the externals say that applications SHOULD assume that buffers are "naturally aligned", so the implementation MUST take that application assumption into account when adjusting any user-requested headroom so there are no alignment "surprises".
Bill On Sun, Nov 9, 2014 at 6:24 PM, Ola Liljedahl <[email protected]> wrote: > On 10 November 2014 00:13, Bill Fischofer <[email protected]> > wrote: > > 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 was more thinking along the lines that you might get more headroom > (aka padding) > than expected because that's the way the Ethernet MAC works. E.g. old > Marvell > Discovery-III "system controller" (it did a lot of other things > besides being an Ethernet MAC) > would always put the Ethernet frame at offset 2 (two bytes of padding) > while requiring > a cache aligned RX buffer (or at east it was feed cache aligned > buffers). This was not > what our network stacks expected. ODP has accessors that should tell you > the > actual start of the frame but the computation of required buffer size > could perhaps get > confused by those unrequested two bytes of extra headroom. > > -- Ola > > > > > 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
