summerq 发表于 2024-5-16 19:19
看过了。我粗略地理解就是 rdma做smb共享时数据包还是要经过内核tcp协议栈，而nvmeof + spdk不用，因此效 ...

如果先不去管RDMA的事，ksmbd思路上还是比较高效的，在内核空间做了处理，省去了用户空间的拷贝。未来看的话，ksmbd + samba，samba + io_uring 都在进行中，还是可以展望的。

我现在的测试本意是想，在存储服务器上，建一个VM专门处理nvmf，再来一个VM专门处理SMB，结果ksmbd这出师不利。。。

summerq 发表于 2024-5-16 22:23
我想我发现原因了。我是在pve内vm上跑ksmbd，nvme通过vfio直通。今天偶尔发现，vfuo的性能有问题。可能真 ...

都测过，PVE是直通网卡，4k高QD都不过千。Windows对连的话，最高两千多吞吐，也就是500K IOPS的样子。当然nvmf轻松超百万

Dolfin 发表于 2024-5-15 20:39
我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/s ...

我想我发现原因了。我是在pve内vm上跑ksmbd，nvme通过vfio直通。今天偶尔发现，vfuo的性能有问题。可能真的要在裸金属上直接测才有说服力。你的测试环境是在pve环境下还是裸金属啊？

Dolfin 发表于 2024-5-15 20:39
我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/s ...

看过了。我粗略地理解就是 rdma做smb共享时数据包还是要经过内核tcp协议栈，而nvmeof + spdk不用，因此效率高。另外，我今天也试过用mellanox官方ofed驱动替换掉内核自带驱动，结果4k依然疲软。我看smb目前就是samba走tcp了，要么就两边都上windows

summerq 发表于 2024-5-15 19:55
拉到如此之低 我怀疑跟rdma的驱动有关系。晚上我编译一个原厂驱动替换试试 ...

我以前问过ksmbd的作者Namjae Jeon关于4k的状况，他推荐我看看这个，也分享给你。https://www.snia.org/sites/default/files/SDC/2017/presentations/smb/Li_Long_Implementing_SMBDirect_for_CIFS.pdf

老饭 发表于 2024-5-15 19:59
why not nvme-of

nvmf是传出去的是块，一对一的，而要共享的话只能用smb nfs这类的文件存储

why not nvme-of

Dolfin 发表于 2024-5-15 19:16
我q32t16从tcp的4000多直接拉到不到800。。我是没搞明白它的传输机制，而且为什么tcp能到那个数字，这超 ...

拉到如此之低 我怀疑跟rdma的驱动有关系。晚上我编译一个原厂驱动替换试试

summerq 发表于 2024-5-15 13:20
刚才又测试了一下：

服务端直通一个1.4T optane 905p

我q32t16从tcp的4000多直接拉到不到800。。我是没搞明白它的传输机制，而且为什么tcp能到那个数字，这超越了物理ssd的性能，内存肯定又参与了。

不过不管怎样，那个文件夹卡顿确实很头疼，重新编译了最新的ksmbd tools也一样，还是不用它搞smb了，弄个win吧

刚才又测试了一下：

服务端直通一个1.4T optane 905p
ksmbd已经启动


rdma开启


客户端win server 2022


结论：
4K确实拉了。。。。。。
但不如你拉的那么厉害。。。。。。

刚才又测试了一下：

服务端直通一个1.4T optane 905p
ksmbd已经启动


rdma开启


客户端win server 2022


结论：
4K确实拉了。。。。。。
但不如你拉的那么厉害。。。。。。

Dolfin 发表于 2024-5-15 11:15
我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到 ...

哦 你说的对哦 我再看看怎么回事 谢谢

Dolfin 发表于 2024-5-15 11:15
我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到 ...

rdma已经打开了 你看我后面两张图 cpu没占用。之所以第一张图里有占用，是因为我用虚拟机，gui是web远程桌面，所以有一些

summerq 发表于 2024-5-15 10:29
1. 没有spdk，只有ksmbd。我这边没有遇见4k暴跌的问题
2. 以前遇见过，现在没有了。这个可能跟内核自带的 ...

我看你现在的测试，1016MB/s 的4k q32t16的数据是在TCP下的成绩（资源管理器还能侦测流量），RDMA下能到多少？

Dolfin 发表于 2024-5-15 09:19
感谢测试，这次测试涉及到SPDK吗？还是只涉及到KSMBD。

从截图看，性能表现很好。

1. 没有spdk，只有ksmbd。我这边没有遇见4k暴跌的问题
2. 以前遇见过，现在没有了。这个可能跟内核自带的ksmbd版本有关系。

summerq 发表于 2024-5-15 02:38
今天跑了一下 我只有25g网卡。linux端是connectx-4 lx，开rdma，ssd是大普微h3200。
window这边环境比较 ...

感谢测试，这次测试涉及到SPDK吗？还是只涉及到KSMBD。

从截图看，性能表现很好。
1.不过RDMA尚未开启。我这开启后，4k Q32T16这个测试就会锐降，几百兆的样子，还不知道该怎么解决。

2.我用KSMBD现在有个奇怪的问题，就是在Windows做客户端访问的时候，打开SMB挂载里的文件夹，经常会出现卡顿，好几秒的样子，切换几个文件夹，打开又会卡顿。不知道你有没有遇到过。

Dolfin 发表于 2024-3-3 15:54
从我的理解来看，小文件随机读写使用的是模式是RDMA  send/receive操作，是一种双边操作，而不像 RDMA re ...

今天跑了一下 我只有25g网卡。linux端是connectx-4 lx，开rdma，ssd是大普微h3200。
window这边环境比较差，是跑在pve上面的一个server 2022虚拟机。cpu是9900k，网卡是connectx-6 dx

iser干脆就通过IB卡PXE识别卷直接安装系统用了。至于windows客户端访问我没试过，设备也卖3年多了

Bloodyevil 发表于 2024-3-3 18:06
小文件读写可以测试下iser应该可以提升不少，以前在Ubuntu环境下搭建过感觉跟本地盘无区别。 ...

Windows作为客户端，除了starwind可以加载iSer，还有什么推荐的？

小文件读写可以测试下iser应该可以提升不少，以前在Ubuntu环境下搭建过感觉跟本地盘无区别。

summerq 发表于 2024-3-3 16:37
首先谢谢您的分享，很有帮助！
我这边会找时间测试一下。我的硬件没有你好，optane已经放在软路由上了， ...

足够的。俩PM983 RAID0多线程高QD肯定也是准百万IOPS了，25GbE的CX4 应付六七十万的IOPS也没问题。就客户端那边控制RDMA开关就行，如果跟我的情况类似，肯定是巨大的差异。

Dolfin 发表于 2024-3-3 13:36
ACM这个文得看一阵子了，感谢分享。
一些关于底层存储的额外说明：
1.实验只用了一块Optane，挂载XFS，测 ...

首先谢谢您的分享，很有帮助！
我这边会找时间测试一下。我的硬件没有你好，optane已经放在软路由上了，所以只能拿两个pm983做raid0，跑spdk+ksmbd作为服务端。客户端是vm上跑win server 2022。网卡也没有你的那么好，我目前能用的只有一个connectx-4 lx 25G

summerq 发表于 2024-3-3 03:11
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 ...

从我的理解来看，小文件随机读写使用的是模式是RDMA  send/receive操作，是一种双边操作，而不像 RDMA read/write 这个模式下的单边操作。前者也更像 TCP下的 send/receive，同时还需要额外的拆解重组，所以效率更低。

SMB Direct 小文件随机读写性能降低就出在这个原因上。

summerq 发表于 2024-3-3 03:11
另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了 ...

ACM这个文得看一阵子了，感谢分享。
一些关于底层存储的额外说明：
1.实验只用了一块Optane，挂载XFS，测试结果看，Ramdisk还是Optane，在本地的性能都是达标的，不管是大文件顺序读写还是4k随机读写。（4k randread IOPS 均超过700K）

2.从SMB的结果来看，Windows下RDMA的小文件随机读写的衰减是显著的（200K上下），而TCP时可以接近700K。那么应该就是在传输这个环节出现了瓶颈，我的猜想就是RDMA对小文件处理并不理想。也期待你的测试，看是不是有类似情况。

3.有空换个系统作客户端再试一下，FIO的数据和CDM类似，都是性能差异过大。不过SMB Direct确实在Windows下场景多一些，要是Linux间的文件共享，也就不用SMB了。

summerq 发表于 2024-3-3 03:08
有几个方向可以试试。
1. 排除掉硬盘带来的影响。用tmpfs创建一个64g的挂载点，然后用ksmbd来试试。ramdisk ...

另外补充一下，windows本身可能是瓶颈，不妨换linux用FIO看一下。如果你一定要用windows客户端就算了

有几个方向可以试试。
1. 排除掉硬盘带来的影响。用tmpfs创建一个64g的挂载点，然后用ksmbd来试试。ramdisk的4k性能是高过经过网络传输的性能的。这样约等于网卡rdma加ksmbd上限的一个测试。
2. 关掉rdma，再用ramdisk试一次。这样可以看出rdma的贡献
3. 关于底层文件系统的影响。我猜你是raid0。假设你用了4个900p，文件系统用了ext4，那么在挂载的时候可以在fstab里加上noatime试试。4k读写性能可能xfs好点。
4. 底层换spdk，用bdev创建挂载点，然后再试一次，这样做的话，底层基本上就没有瓶颈了。假设你4个optane做raid0，你就分配4个cpu物理核心跑

关于延迟，有篇文章讲的很棒
https://dl.acm.org/doi/fullHtml/10.1145/3462545

aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s

另外这有缓冲区的影响

aixunxian 发表于 2024-3-2 14:55
为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s

硬盘规格就不行，写入指标不到读取的一半

Dolfin 发表于 2024-3-1 10:09
我这是Windows NAS，不用猜了。

为啥你这个cdm跑出来顺序写入这么低呢？顺读都11G/s了写咋才5G/s