[dpdk-dev] [PATCH 00/10] Improve cast alignment for strict aligned machines

[Cyril Chemparathy]

On Mon, 4 May 2015 11:50:09 +0200
Olivier MATZ <olivier.matz at 6wind.com> wrote:

> Hi Cyril,
> 
> On 04/29/2015 06:15 PM, Cyril Chemparathy wrote:
> > This series contains a few improvements that allow the DPDK code
> > base to build properly on machines that enforce strict pointer cast
> > alignment constraints.
> > 
> > When dealing with packet data which could be arbitrarily aligned,
> > we get the compiler to do the right thing by (a) making sure that
> > header types are packed, and (b) introducing and using
> > unaligned_uint(16|32|64)_t types when upcasting from byte pointers.
> > 
> > In a few other instances, we know apriori that the pointer cast
> > cannot possibly break alignment.  This applies to the changes in
> > mempool, hash, mbuf, and the ethdev stats code.  Here, we simply
> > silence the compiler by casting through (void *) using the
> > RTE_PTR_(ADD|SUB) macros.
> > 
> > Finally, we introduce a new rte_pktmbuf_mtod_offset() helper to
> > return a type casted pointer to an offset within the packet data.
> > This replaces the following commonly used pattern:
> > 	(struct foo *)(rte_pktmbuf_mtod(m, char *) + offset)
> > with:
> > 	rte_pktmbuf_mtod_offset(m, struct foo *, offset)
> > To ensure consistency, the above transform was applied throughout
> > the code base using the coccinelle semantic patching tool.
> > 
> 
> Before diving into the patches, I'm wondering if adding aligned(1) or
> (packed) attribute at some places would have a performance impact on
> supported architectures (Intel or IBM Power). Did you manage to test
> it?
> 

I don't expect to see a performance impact on x86.  I don't really
have a way of trying this out on PPC, and I could use some help here.

Overall, I think that the few places where we've injected aligned(1) or
packed really warrant the insertion for correctness.  These are places
where packet data of unknown alignment is being typecast and
dereferenced.  In such cases, _not_ representing the unaligned
nature of these accesses breaks machines with strict alignment.

Thanks
-- Cyril.