[zeromq-dev] ØMQ VSM data alignment

[Andrew Hume]

this sort of thing can get problematic quickly.
the combinatorial explosion of cache-line design, memory design,
language alignment rules, architectures allowing non-aligned references
(but punishing you with slowness) makes testing hard.

on the other hand, starting on a 8 byte boundary is always a good  
idea in modern architectures.

better style is to use a byte stream so you won't get bitten by LSB/ 
MSB issues
or packets coming from other machine architectures.

andrew

On Aug 4, 2010, at 1:09 PM, Pieter Hintjens wrote:

> Matt,
>
> I don't think this has been covered.  It would be sensible to have
> vsm_data aligned but it's something that is IMO worth testing rather
> than doing on faith.
>
> -Pieter
>
>> Sorry if this has been covered before.
>> I've been using zmq to transport raw structures, and I've noticed  
>> that
>> zeromq apparently does not provide appropriate alignment for  
>> messages in
>> VSMs, and maybe for larger messages as well if you're using the  
>> front of the
>> content buffer (I haven't looked :-( )
>> Here are the offsets:
>>
>> 0x00    void *content;
>> 0x08    unsigned char flags;
>> 0x09    unsigned char vsm_size;
>> 0x0a    unsigned char vsm_data [ZMQ_MAX_VSM_SIZE];
>>
>> Shouldn't vsm_data be padded to 0x10 on 64 bit architectures (and  
>> maybe
>> others)?
>> RSVP,
>> Thanks,
>> Matt
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>

------------------
Andrew Hume  (best -> Telework) +1 732-886-1886
andrew at research.att.com  (Work) +1 973-360-8651
AT&T Labs - Research; member of USENIX and LOPSA



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100804/8a328999/attachment.htm>