svn commit: r300868 - head/tools/tools/ioat

[Conrad Meyer]

I don't think such infrastructure is needed for simple test code like
this.  128 is more than enough.

On Fri, May 27, 2016 at 1:51 PM, Ngie Cooper (yaneurabeya)
<yaneurabeya at gmail.com> wrote:
>
>> On May 27, 2016, at 13:34, Conrad Meyer <cem at FreeBSD.org> wrote:
>>
>> On Fri, May 27, 2016 at 1:12 PM, Garrett Cooper <ngie at freebsd.org> wrote:
>>> Author: ngie
>>> Date: Fri May 27 20:12:32 2016
>>> New Revision: 300868
>>> URL: https://svnweb.freebsd.org/changeset/base/300868
>>>
>>> Log:
>>>  Remove note about bogus chain-len maximum
>>>
>>>  There's no current limit on chain-len with Broadwell DE chips; it isn't
>>>  enforced in software, and there doesn't appear to be a hardware limitation
>>>  either on the Intel Xeon D-1527 (Broadwell-DE) chip.
>>
>> Hi Ngie,
>>
>> The note isn't bogus, it's just not what you think it is—the limit is
>> in the ioat_test code, not a limit of the hardware.
>>
>> Before this commit which documented it (r289733), the limit *was* 4.
>> However, in the same commit I bumped the limit up to 128
>> (IOAT_MAX_BUFS / 2).  (I suspect I wrote the documentation first,
>> before deciding to raise the limit.)
>>
>> So the current limit is 128, and should be documented.
>
> Ah… that makes sense. Would it be a better idea to make this limit into a readonly sysctl in ioat_test(4), along with the other limits? If so, I’ll put that out for CR.
> Thanks,
> -Ngie