On Sunday 04 November 2012 11:29:29 Sven Eckelmann wrote:
On Saturday 03 November 2012 15:22:26 David Miller wrote: [...]
Your packet layouts are very poorly designed and I want you to stop and think seriously about things before extending things further.
You are right about the packet design/layout. But I also have some problems with the following statement. Maybe you can help me to resolve it.
All of this __packed stuff is a serious problem.
It means that on RISC system, fields such as your 32-bit sequence number, will be read and written using byte loads and stores.
This is terrible.
Instead, design the structures so that they are full filled out to at least 4 byte boundaries, so that they and the contents after them, are 4 byte aligned too.
Then you won't need to mark all of your packet header structs with __packed, and therefore the compiler can use full 32-bit loads and stores to access 32-bit fields.
Ok, lets assume batman-adv has everything 4 byte aligned and we are running on a machine without unaligned r/w access. The machine may issues bus errors and so on.
Now also assume following really unusual situation: We get our data from a ethernet driver and the skb stores the ethernet header. The start of the ethernet header is perfectly aligned (4 or even 16 byte boundary aligned). The the header is 14/18 byte long (6 byte src, 6 byte dst, 2 byte ethertype and maybe 4 byte vlan). Now the payload starts only on a 2 byte boundary -> it is never 4 byte boundary aligned. A 32 bit read now causes different variations of problems (reminder: bus error).
This brings me to the question: Why should the "32 bit align everything relative to the start of the struct" approach help to resolve the situation for the access of 32 bit data structure members? May I am missing some information?
To push this question in a direction: May I assume that the driver always ensures that the ethernet header is 4 byte boundary - NET_IP_ALIGN (2) aligned?
When yes, this would result in a slight variations of your suggestion: unicast/bcast headers have to end at 4 bytes boundary + 2 bytes. The reason is easy to explain. batman-adv unicast/bcast headers are used to encapsulate the important parts of an ethernet frame:
Ethernet Header for P2P | batman-adv header stuff | ethernet header | payload.
Would you aggree?
Thanks, Sven