svn commit: r308869 - head/sbin/nvmecontrol

[Jan Bramkamp]

On 21/11/2016 19:07, John Baldwin wrote:
> On Saturday, November 19, 2016 09:46:13 PM Warner Losh wrote:
>> Author: imp
>> Date: Sat Nov 19 21:46:13 2016
>> New Revision: 308869
>> URL: https://svnweb.freebsd.org/changeset/base/308869
>>
>> Log:
>>   i386 turns out to not have __uint128_t. So confusingly use 64-bit math
>>   instead. Since we're little endian, we can get away with it. Also,
>>   since the counters in quesitons would require billions of iops for
>>   tens of billions of seconds to overflow, and since such data rates are
>>   unlikely for people using i386 for a while, that's OK. The fastest
>>   cards today can't do even a million IOPs.
>>
>>   Noticed by: dim@
>>   Sponsored by: Netflix, Inc
>
> It probably has it if you compile with -march=<foo> where <foo> is new
> enough to have SSE.

In that case you have 128-bit registers. Starting with SSE2 you use 
those registers for 4 x 32-bit integer computations but irrc SSE lacks 
efficient carry operations. It's probably still more efficient to user 
32-bit integer registers for bignum operations unless you want to 
(ab-)use the 53-bit multipliers hidden inside the FPUs.

I don't know if correctly aligned memory transfers between SSE registers 
and memory are atomic. Unless SSE can provide this guarantee there 
advantage to polluting the code with SIMD built-ins.

> Is nvme inherently x86-only?

No.