Structure alignment problems in PCUIFv9 and PCUIFv10

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Sep 21 12:57:34 UTC 2020


On Fri, Sep 18, 2020 at 03:51:54AM +0700, Vadim Yanitskiy wrote:
> we seem to have problems with structure alignment in the new version of
> the PCUIF protocol:
> 
>   PCUIFv9:  sizeof(struct gsm_pcu_if) ->  212;  212 % 4 == 0
>   PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0

the total size of the struct doesn't really matter that much.
> 
> I think we would need to add/remove some padding.  The question is
> whether we should make sure that all structures are aligned, or having
> the top level struct gsm_pcu_if aligned would be enough?

I think what is important is that the individual fields / members are aligned
at the natural alignment boundary of the most common architectures (so,
let's say to DWORD boundary).  Of course, for an uint8_t it may not be as relevant as for an
unaligned uint32_t in the middle of a struct.

Otherwise each access to a member will cause unaligned accesses, which may
be more expensive depending on your architecture.  Even though ARMV7 suppors
unaligned loads/stores, they are apparently still slower than aligned ones.

For an INFO_IND that doesn't matter, but for primitives/message we exchange
at high frequency it may matter.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list