In the virtualization scenario, you can use pvipi to optimize the sending of
IPI interrupts and reduce the number of vmexit.
rps_using_pvipi test
Test guest: 32 core, 64G memory, virtio-net 8 queues, rss interrupt is bound
to 24-31 core. Observe the number of vmexit of 31 cores.
1. 1000000pps
100 iperf instances, 10000pps per instance.
disable rps_using_pvipi 68077 vmexit/s
enable rps_using_pvipi 21138 vmexit/s
2. 2000000pps
1000 iperf instances, 2000pps per instance.
disable rps_using_pvipi 40879 vmexit/s
enable rps_using_pvipi 9195 vmexit/s
3. 2000000pps
2000 iperf instances, 1000pps per instance.
disable rps_using_pvipi 24746 vmexit/s
enable rps_using_pvipi 7292 vmexit/s
Enabling rps_using_pvipi can greatly reduce the number of vmexit.
Signed-off-by: yongduan <yongduan@tencent.com>
[tkernel2 commit c6f2e27f7ad]
add SO_MARK2 to get the MARK of flow
Signed-off-by: brookxu <brookxu@tencent.com>
Signed-off-by: Zhiping Du <zhipingdu@tencent.com>
When use-gss-proxy is set to 1, write_gssp will lead to 2 get_net calls
in gssp_rpc_create, the paired put_net calls are supposed to be made
in rpcsec_gss_net_ops->exit i.e. rpcsec_gss_exit_net, but this will
never happen because rpcsec_gss_exit_net (via ops_exit_list) is called
by cleanup_net and cleanup_net will never run unless net->count becomes
0, since the paired put_net calls of gssp_rpc_create are not made yet,
net->count cannot drop to 0. This is dead lock situation.
This fix introduced a new method i.e. evict in struct proc_ns_operations,
which is called in nsfs_evict, moving rpcsec_gss_exit_net into the code
path of nsfs_evict gives it a chance to run.
Signed-off-by: Wenbin Zeng <wenbinzeng@tencent.com>
upstream commit: a3dcaf17ee54f1d01d22cc2b22cab0b4f60d78cf
As we want to gradually implement per netns sysctl_rmem and sysctl_wmem
on per protocol basis, add two new fields in struct proto,
and two new helpers : sk_get_wmem0() and sk_get_rmem0()
First user will be TCP. Then UDP and SCTP can be easily converted,
while DECNET probably wont get this support.
Signed-off-by: Hongbo Li <herberthbli@tencent.com>