On 2020/03/25 1:51, Tokunori Ikegami wrote:
On 2020/03/24 9:02, Keith Busch wrote:
On Tue, Mar 24, 2020 at 08:09:19AM +0900, Tokunori Ikegami wrote:
Hi,
The change looks okay, but why do we need such a large data length ?
Do you have a use-case or performance numbers ?
We use the large data length to get log page by the NVMe admin command.
In the past it was able to get with the same length but failed
currently
with it.
So it seems that depended on the kernel version as caused by the
version up.
We didn't have 32-bit max segments before, though. Why was 16-bits
enough in older kernels? Which kernel did this stop working?
Now I am asking the detail information to the reporter so let me
update later.
That was able to use the same command script with the large data
length in the past.
I have just confirmed the detail so let me update below.
The data length 20,531,712 (0x1394A00) is used on kernel 3.10.0 (CentOS
64bit).
Also it is failed on kernel 10 4.10.0 (Ubuntu 32bit).
But just confirmed it as succeeded on both 4.15.0 (Ubuntu 32bit) and
4.15.1 (Ubuntu 64bit).
So the original 20,531,712 length failure issue seems already resolved.
I tested the data length 0x10000000 (268,435,456) and it is failed
But now confirmed it as failed on all the above kernel versions.
Also the patch fixes only this 0x10000000 length failure issue.
There was confused and sorry for that.
Regards,
Ikegami
