RE: [kmip] Groups - Sun 64-bit Binary Alignment Proposal v2 (Sun 64-bit Binary Alignment Proposal.pdf) uploaded

["Scott Kipp" <skipp@Brocade.COM>]

Matt,

When I look at your two most recent proposals posted on the 6th and the
1st, here is a summary of the different values in section 9.1.1:

Proposal	Item Tag	Item Type
32 Bit	32 bits	32 bits
64 bit	3 byte	1 byte

Please help me understand where the 16 bit fields are.

Do you have any data as to how long it will take to process 32 bit or 64
bit fields with 64 bit processors?  Won't the difference be in the
microsecond range?  I don't think they will amount to much difference.

Thanks,
Scott

-----Original Message-----
From: Matthew.Ball@Sun.COM [mailto:Matthew.Ball@Sun.COM] 
Sent: Wednesday, May 06, 2009 11:37 AM
To: Scott Kipp
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - Sun 64-bit Binary Alignment Proposal v2
(Sun 64-bit Binary Alignment Proposal.pdf) uploaded

Hi Scott,

See responses below:

Scott Kipp wrote:
> Matt,
>
> This 64-bit proposal only has a 1-octet type field while the 32-bit 
> proposals type field has 4 octets.  I would have thought the 64-bit 
> proposal would expand the type field to a 4 octet field to be in 
> alignment with the 32-bit proposal.  I think the 64-bit proposal will 
> run into scalability problems if the type field only has 256 values as

> others have said.
>   
[Matt] I think you're confusing the Type for the Tag field here. 
Previous, we were concerned with limiting the _Tag_ field to 8 usable
bits.  I don't know of anyone worried about expanding the Type field
beyond 8 bits because Types are fundamental to the parser and are
unlikely to change (at least without breaking all backwards
compatibility).  Conversely, we expect moderate expansion of the Tag
field, and both the 32-bit and 64-bit proposals allow 16-bits for this
(i.e., both the 32-bit and 64-bit proposals are identical in this
regard).
> All,
>
> I won't be on the call tomorrow, so I want to say why I voted for the 
> 32-bit alignment.  There are many ways to specify this and our goal 
> should be to pick the optimal one.  The two options we are considering

> is to optimize the bits on the wire (and thus the bits in storage) 
> with the 32-bit alignment or optimize the processor performance for 
> 64-bit processors with 64-bit alignment.
>   
[Matt] I want to be very clear that the 64-bit alignment proposal does
not make it hard for 32-bit processors.  The 64-bit alignment proposal
is equally suitable to either 32-bit or 64-bit processors.  Let me
clarify, if possible:

In the 64-bit proposal, the Tag and Type fields are combined into a
single 32-bit word, making it optimal for 32-bit processors.  The length
field is also 32-bits, making it optimal for 32-bit processors.  The
combination of the Tag, Type, and Length fields fits nicely into
64-bits, making it additionally optimal for 64-bit processors.  In the
64-bit proposal, the data field is padded out to multiples of 8 bytes,
which still works find on a 32-bit processor.

Thanks,
-Matt