@sleepingdog 哦，那样的话应该是要克隆除盘 1 剩下的所有正常盘

@sleepingdog 你的意思是假设我现在出问题的是盘 1 ，推荐的做法是先克隆盘 1 到新盘，然后挂新盘到 nas 上去重建吗？

@dode
@ryd994 重建完成了，mdadm -D /dev/md0 显示也是“active sync”。但是重启之后还是"removed". 看起来可能搬运过程中硬盘搞坏了。但是我不明白的是为什么重建可以完成。哎，只能先备份数据了。后面换一块硬盘试试看。

@dode
重插不行，已在后台使用 mdadm /dev/md0 -a /dev/sda3 重建，战战兢兢中。听说很多人在 rebuild 中失败然后全部找不到。

@Drumming 已卖光

@keyfunc 取决于你的固件，openwrt 的防火墙配置很简单。需要手动开放某个端口 v6 才能从 internet 访问内部机器。

@Leao9203 前面已经说了.你这样是搜索不到的，一般是需要 intel 的人员提供
>有人不愿意分享，毕竟带有保密性质

办过。要是能多优惠几年就更好了，哈哈。

>65.79 的套餐
月付吗？

@FabricPath . 设置了 smp_affinity_list 。eth0 为 wan ，eth1 （ 10g 测试机连接），eth2 ，eth3 为 lan 。 （ 51,56,61 ，66 应该就是管理中断）
root@OpenWrt:~# grep eth /proc/interrupts
47: 11684059 0 0 0 ICU-NSR 39 Level eth0
48: 0 1767000 0 0 ICU-NSR 43 Level eth0
49: 0 0 1748609 0 ICU-NSR 47 Level eth0
50: 0 0 0 2103639 ICU-NSR 51 Level eth0
51: 4 0 0 0 ICU-NSR 129 Level eth0
52: 5962016 0 0 0 ICU-NSR 39 Level eth1
53: 0 873775 0 0 ICU-NSR 43 Level eth1
54: 0 0 957364 0 ICU-NSR 47 Level eth1
55: 0 0 0 566200 ICU-NSR 51 Level eth1
56: 16 0 0 0 ICU-NSR 129 Level eth1
57: 7114790 0 0 0 ICU-NSR 40 Level eth2
58: 0 82885 0 0 ICU-NSR 44 Level eth2
59: 0 0 71360 0 ICU-NSR 48 Level eth2
60: 0 0 0 107930 ICU-NSR 52 Level eth2
61: 1 0 0 0 ICU-NSR 128 Level eth2
62: 0 0 0 0 ICU-NSR 41 Level eth3
63: 0 0 0 0 ICU-NSR 45 Level eth3
64: 0 0 0 0 ICU-NSR 49 Level eth3
65: 0 0 0 0 ICU-NSR 53 Level eth3
66: 0 0 0 0 ICU-NSR 127 Level eth3

root@OpenWrt:~# cat /proc/irq/47/smp_affinity_list
0
root@OpenWrt:~# cat /proc/irq/48/smp_affinity_list
1
root@OpenWrt:~# cat /proc/irq/49/smp_affinity_list
2
root@OpenWrt:~# cat /proc/irq/50/smp_affinity_list
3
root@OpenWrt:~# cat /proc/irq/52/smp_affinity_list
0
root@OpenWrt:~# cat /proc/irq/53/smp_affinity_list
1
root@OpenWrt:~# cat /proc/irq/54/smp_affinity_list
2
root@OpenWrt:~# cat /proc/irq/55/smp_affinity_list
3

但从测试看，没有 rps 分布均匀。所以跑到较好的速度的概率小很多。可能要跑个 pt/bt 下载才能知道。speedtest session 太少了。
root@OpenWrt:~# ethtool -n eth0 rx-flow-hash tcp4
TCP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

@FabricPath
>你这个 CPU 不是只有 4 个核心么，只有 4 个 bit ，所以 rps 是 0000 - 1111 （ 0~F)
犯了了个低级错误，我 echo 用的是 10 进制。echo e 好了。最好的情况可以跑到 3200+了。此时 cpu 1,2,3 跑满。
04:07:02 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
04:07:04 all 0.00 0.00 0.25 0.00 0.00 83.50 0.00 0.00 0.00 16.25
04:07:04 0 0.00 0.00 0.50 0.00 0.00 38.50 0.00 0.00 0.00 61.00
04:07:04 1 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00
04:07:04 2 0.00 0.00 0.50 0.00 0.00 96.50 0.00 0.00 0.00 3.00
04:07:04 3 0.00 0.00 0.00 0.00 0.00 99.00 0.00 0.00 0.00 1.00

https://www.speedtest.net/result/c/c0424651-4045-4a30-a408-fc84fc7a0917 。

后面我再研究一下 rss 。看是否不要 rps ，最好是能用 rss 。

@FabricPath 测试了一下 ntuple, 出错了，还在 debug
root@OpenWrt:~# ethtool -N eth0 flow-type ether dst 32:2F:61:11:3B:69 action 1
rmgr: Invalid RX class rules table size: Not supported
Cannot insert classification rule

@FabricPath
>这个 4*A72 跑满 3Gbps 上下行还挺吃力的，不知道他的 Packet Processor 包含什么功能。
这里 BLOCK DIAGRAM 有： https://en.sekorm.com/doc/1816470.html
不知道 Packet Processor 在转发的时候是否可以在 openwrt 用上。可能是用在"ODP (Open Data Plane) compliant"?

另外 ntuple 默认是打开的。上述连接也说了 ntuple 是支持的。
root@OpenWrt:~# ethtool -k eth0 |grep ntuple
ntuple-filters: on [fixed]

@FabricPath tx 看起来好一些。txq0-txq3 都有，txq4-txq7 没有。
root@OpenWrt:~# ethtool -S eth0 |grep txq
txq_0_desc_enqueue: 20993833
txq_0_desc_enqueue_to_ddr: 0
txq_0_buff_euqueue_to_ddr: 20993833
txq_0_desc_hardware_forwarded: 0
txq_0_packets_dequeued: 20989169
txq_0_queue_full_drops: 0
txq_0_packets_early_drops: 0
txq_0_packets_bm_drops: 0
txq_0_packets_rep_bm_drops: 0
txq_1_desc_enqueue: 4127091
txq_1_desc_enqueue_to_ddr: 0
txq_1_buff_euqueue_to_ddr: 4127091
txq_1_desc_hardware_forwarded: 0
txq_1_packets_dequeued: 4127023
txq_1_queue_full_drops: 0
txq_1_packets_early_drops: 0
txq_1_packets_bm_drops: 0
txq_1_packets_rep_bm_drops: 0
txq_2_desc_enqueue: 3610058
txq_2_desc_enqueue_to_ddr: 0
txq_2_buff_euqueue_to_ddr: 3610058
txq_2_desc_hardware_forwarded: 0
txq_2_packets_dequeued: 3609977
txq_2_queue_full_drops: 0
txq_2_packets_early_drops: 0
txq_2_packets_bm_drops: 0
txq_2_packets_rep_bm_drops: 0
txq_3_desc_enqueue: 1103662
txq_3_desc_enqueue_to_ddr: 0
txq_3_buff_euqueue_to_ddr: 1103662
txq_3_desc_hardware_forwarded: 0
txq_3_packets_dequeued: 1103615
txq_3_queue_full_drops: 0
txq_3_packets_early_drops: 0
txq_3_packets_bm_drops: 0
txq_3_packets_rep_bm_drops: 0
txq_4_desc_enqueue: 0
txq_4_desc_enqueue_to_ddr: 0
txq_4_buff_euqueue_to_ddr: 0
txq_4_desc_hardware_forwarded: 0
txq_4_packets_dequeued: 0
txq_4_queue_full_drops: 0
txq_4_packets_early_drops: 0
txq_4_packets_bm_drops: 0
txq_4_packets_rep_bm_drops: 0
txq_5_desc_enqueue: 0
txq_5_desc_enqueue_to_ddr: 0
txq_5_buff_euqueue_to_ddr: 0
txq_5_desc_hardware_forwarded: 0
txq_5_packets_dequeued: 0
txq_5_queue_full_drops: 0
txq_5_packets_early_drops: 0
txq_5_packets_bm_drops: 0
txq_5_packets_rep_bm_drops: 0
txq_6_desc_enqueue: 0
txq_6_desc_enqueue_to_ddr: 0
txq_6_buff_euqueue_to_ddr: 0
txq_6_desc_hardware_forwarded: 0
txq_6_packets_dequeued: 0
txq_6_queue_full_drops: 0
txq_6_packets_early_drops: 0
txq_6_packets_bm_drops: 0
txq_6_packets_rep_bm_drops: 0
txq_7_desc_enqueue: 0
txq_7_desc_enqueue_to_ddr: 0
txq_7_buff_euqueue_to_ddr: 0
txq_7_desc_hardware_forwarded: 0
txq_7_packets_dequeued: 0
txq_7_queue_full_drops: 0
txq_7_packets_early_drops: 0
txq_7_packets_bm_drops: 0
txq_7_packets_rep_bm_drops: 0

receive-hashing 也有，但默认关闭了。
root@OpenWrt:~# ethtool -k eth0 |grep hash
receive-hashing: off
开启之后，rx 可以均匀分布了，但是还是全部在一个 cpu 上，能跑到 900 多。
root@OpenWrt:~# ethtool -S eth0 |grep rxq
rxq_0_desc_enqueue: 26346082
rxq_0_queue_full_drops: 95608
rxq_0_packets_early_drops: 0
rxq_0_packets_bm_drops: 0
rxq_1_desc_enqueue: 2242533
rxq_1_queue_full_drops: 2057
rxq_1_packets_early_drops: 0
rxq_1_packets_bm_drops: 0
rxq_2_desc_enqueue: 2389831
rxq_2_queue_full_drops: 1742
rxq_2_packets_early_drops: 0
rxq_2_packets_bm_drops: 0
rxq_3_desc_enqueue: 4022202
rxq_3_queue_full_drops: 50
rxq_3_packets_early_drops: 0
rxq_3_packets_bm_drops: 0
如果在此基础上，使用下列命令，最好的情况（恰好 loading 被均匀分布）可以跑到 2100+。此时 cpu 1 和 cpu2 被吃满了。
for rxq in /sys/class/net/eth[01]/queues/rx*; do echo 6 > $rxq/rps_cpus; done

03:06:23 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:06:25 all 0.00 0.00 0.25 0.00 0.00 56.00 0.00 0.00 0.00 43.75
03:06:25 0 0.00 0.00 0.50 0.00 0.00 17.00 0.00 0.00 0.00 82.50
03:06:25 1 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00
03:06:25 2 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00
03:06:25 3 0.00 0.00 0.50 0.00 0.00 7.00 0.00 0.00 0.00 92.50
https://www.speedtest.net/result/c/d143eb75-99a3-4625-900e-3c77cb9172e9

我想把 rps 分布到 cpu1 ，cpu2 ，cpu3 ，这样可能还可以提一提. 不知道为什么 echo 14 会出错。echo 8 可以
root@OpenWrt:~# for rxq in /sys/class/net/eth[01]/queues/rx*; do echo 14 > $rxq/rps_cpus; done
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type
ash: write error: Value too large for data type

@FabricPath 看起来是单队列。有办法确认网卡是否支持 pppoe 的 rss 吗？默认不配置 RPS 下，cpu0 几乎被吃满。并且发现测试下载的时候 rxq_0_queue_full_drops 数量会增加。

root@OpenWrt:~# ethtool -S eth0 |grep rxq
rxq_0_desc_enqueue: 9300296
rxq_0_queue_full_drops: 84685
rxq_0_packets_early_drops: 0
rxq_0_packets_bm_drops: 0
rxq_1_desc_enqueue: 0
rxq_1_queue_full_drops: 0
rxq_1_packets_early_drops: 0
rxq_1_packets_bm_drops: 0
rxq_2_desc_enqueue: 0
rxq_2_queue_full_drops: 0
rxq_2_packets_early_drops: 0
rxq_2_packets_bm_drops: 0
rxq_3_desc_enqueue: 0
rxq_3_queue_full_drops: 0
rxq_3_packets_early_drops: 0
rxq_3_packets_bm_drops: 0

@FabricPath 感谢分享。v 站有水平的真多。我晚上回家看看。

我现在是把中断上半部分放在 cpu0 上，cpu1 和 cpu2 做下半部分。晚上贴上 cpu loading. 记忆中 cpu0 差不多跑满了。cpu1 和 cpu2 还剩一些。

我分析了一下可能的性能热点。

1. cpu 需要打 tag 和去 tag 。
2. cpu 需要做 pppoe
3. 因为是单线多拨，使用了 kernel 的 macvlan 。macvlan 是不是 slow path?

openwrt 已经开启了 flow table （ fast path ）。在上述条件下，fast path 是不是还能工作，还是只能部分工作？

另外，我用的 soc 是 Marvell ARMADA 8040： http://macchiatobin.net/product/macchiatobin-double-shot/

@FabricPath 现在是路由负载过重，跑不到期待的速率。

@FabricPath 其实我不是 1G. 在我的测试 /折腾环境下我期待能跑到接近 4G （ 3 个 1000M 账号）。所以我希望能充分利用每个硬件。

@LGA1150 应该是不支持的。
root@OpenWrt:~# ethtool -k eth0 |grep vlan
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
rx-vlan-filter: off
vlan-challenged: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]