@huguadao 目前应该是没有任何变化吧

@huguadao 关于“个人免费版只能有一个账号还是免费 N 个账号”同样不清楚，期待与客服明确的来分享。我这与客服申请切回 Legacy free 后台没有变化，与客服再次确认了后台的收费时间表后，得到明确未来不会收费的答复。现在就是等等看

@SkyLanD Nice! 补充了只能从 Business Starter 转个人免费使用。我是 Business Starter

@huguadao 哈哈，已升级的，目前看处理方案是停留在 Google Workspace edition(但承诺个人使用不收费)，而不是退回 G Suite legacy free edition ，所以这种方式是不是以后仍可随时更换主域名啦。(没准会随时阉割功能啦，至少个人使用免费版明确不包括 7x24 小时支持

与客服再次确认了一下，确定未来不需付费了。

@zdf 我这订阅进去还是有收费时间表的，此时还处于免费阶段，不知道何时会更新，不过利用这次把主域名给换了。另外，个人使用具体规则不知道是什么，只能一个用户？

之前已升级的，联系客服回退，答复:

Google Workspace Support, Aldwin: Fantastic! Thank you for choosing! I’ve noted that you are interested in an alternative Workspace experience at no cost. You can continue to enjoy your Google Workspace edition for no cost. You will not be billed for your Google Workspace account for the foreseeable future. No further action is needed at this time.

可是刷新 Admin 的订阅页面还是有付费时间表的，再等等看吧~

坑了，已升级还能回退吗

@geekvcn 哈哈，确实不是非常清楚 TSO/GSO 的实现细节，结合平时的使用感受(我的 r8169 网卡不支持 TSO)就“推测”了一把，好在被及时指正了 :P

nanopi-m4 + usb3 硬盘盒 + btrfs + nginx-webdav/sftp

@geeglo 感谢 @FabricPath 前面说法被证伪了，刚才查了一下资料也做了一下实验，开启 TSO 或 TSO 时，在 netfilter 确实是合并后的大 skb 。

@geeglo 有结论来分享一下哈，把推测证实或证伪，细节具体化，感谢~

@geeglo iptables 可以过滤到 tcp 流中每一个具体的 packet 的转发与否，所以可推测这种情况下在与网卡的交互上没有启用相关的硬件加速技术。记得之前在有些光猫上使用 iptables 实现某些操作还需要关闭硬件加速，否则根本走不到 iptables 的路径上。

具体情况具体对待吧，利用好硬件加速会更香。

@geeglo
@ryd994

我理解当有网卡加速来处理 tcp stream 与 iptables 处理 raw packet 的区别，借用快递类似的话，接收：raw packet 是能一次运送(DMA)很多个 packet ，且每个 packet 都带有收发人地址，快递员到达时按一下门铃(中断)让接收人（ CPU ）处理，CPU 需要修改每个 packet 上的收发人地址。而 tcp stream 的话，网卡收到若干个 raw packet ，将同一个 tcp stream 的 packet 在网卡上合并成一个较大的 packet ，大 packet 只带有一个收发人地址(因为同 stream 都相同)，通知 CPU 处理，CPU 只需改一次收发人地址即可。在内核态、用户态交互上，只要 buffer 不大小，上下文切换的次数也是比较少的。

从转发节点内部来看，用户态转发比 iptables 肯定包括了更多的上下文切换以及可能更多的 copy 开销。用户态转发是两条 tcp stream ，且有缓冲； iptables 转发是 raw packet 转发；考虑到网络延迟及对流控的影响，转发节点内部开销不一定是决定性因素。

{ dpdk, raw socket packet mmap, xdp } + busyloop

@revlis7 那就说明肯定是啦，这事就有意思了

就在此时此刻做个不加 @vip1 后辍的对比呀

2606:4700:00f4:: 46.1 ms
2606:4700:83b0:: 44.1 ms
2606:4700:90c0:: 45.1 ms
2606:4700:90d0:: 48.6 ms
2606:4700:91b0:: 45.4 ms
2606:4700:9640:: 44.3 ms
2606:4700:9760:: 42.7 ms
2606:4700:99e0:: 41.2 ms
2606:4700:9a90:: 43.5 ms
2606:4700:9ad0:: 44.0 ms
2606:4700:9ae0:: 46.2 ms
2606:4700:9b00:: 44.7 ms
2606:4700:9c60:: 44.8 ms