xiaoxiang781216 commented on a change in pull request #5154:
URL: https://github.com/apache/incubator-nuttx/pull/5154#discussion_r778201656
##########
File path: include/nuttx/net/usrsock.h
##########
@@ -227,9 +228,9 @@ begin_packed_struct struct usrsock_message_req_ack_s
{
struct usrsock_message_common_s head;
- uint8_t xid;
- uint8_t reserved;
- int32_t result;
+ int16_t reserved;
Review comment:
> @xiaoxiang781216 that is exactly what I have started from. The usecase
is either native alignment
We can't leverage the compiler do the native alignment as discuss before
since the different compiler may align to the different place.
> or `packed`.
packed can ensure all compiler place the field in the same location which is
important for IPC.
> In Bothell cases any `reserved` does not make any sense because in case of
native alignment all "reserved" will be added by the compiler and in case of
`packed` to padding will be done.
packed will remove any pad from the struct, so if we don't add some reserved
field here, many fields will become unalignment. This will impact the
performance and code size:
1. If the hardware doesn't support unaligned access, compiler will split the
bus transaction into small and aligned, which increase code size and decrease
performance both.
2. If the hardware does support unaligned access, compiler will issue the
access directly, and hardware will split it into small and aligned if the
access isn't aligned. In this case, only the performance get impact.
> Maybe I'm missing something, but please point me to why do we need to add
any `reserved` into the structures?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
