Re: [vpp-dev] test performance of nginx using vpp host stack#vpp-hoststack
Hi, Understood. See the comments in my previous reply regarding timewait-time (tcp_max_tw_bucket practically sets time-wait to 0 once threshold is passed) and tcp-src address. Regards, Florin > On Apr 30, 2022, at 10:08 AM, weizhen9...@163.com wrote: > > Hi, > I test nginx proxy using RPS. And nginx proxy only towards one IP. > Now I test the performance of nginx proxy using vpp host stack and by > configuring nginx, it is a short connection between the nginx reverse proxy > and the upstream server. The result of test show that the performance of > nginx proxy using vpp host stack is lower than nginx proxy using kernel host > stack. In kernel host stack, I config tcp_max_tw_bucket. > But when it is a long connection between the nginx reverse proxy and the > upstream server, the performance of nginx proxy using vpp host stack is > higher than nginx proxy using kernel host stack. > So what should I do to improve the performance of nginx proxy using vpp host > stack when it is a short connection between the nginx reverse proxy and the > upstream server? > Thanks. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21313): https://lists.fd.io/g/vpp-dev/message/21313 Mute This Topic: https://lists.fd.io/mt/90793836/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] test performance of nginx using vpp host stack#vpp-hoststack
Hi, I test nginx proxy using RPS. And nginx proxy only towards one IP. Now I test the performance of nginx proxy using vpp host stack and by configuring nginx, it is a short connection between the nginx reverse proxy and the upstream server. The result of test show that the performance of nginx proxy using vpp host stack is lower than nginx proxy using kernel host stack. In kernel host stack, I config tcp_max_tw_bucket. But when it is a long connection between the nginx reverse proxy and the upstream server, the performance of nginx proxy using vpp host stack is higher than nginx proxy using kernel host stack. So what should I do to improve the performance of nginx proxy using vpp host stack when it is a short connection between the nginx reverse proxy and the upstream server? Thanks. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21312): https://lists.fd.io/g/vpp-dev/message/21312 Mute This Topic: https://lists.fd.io/mt/90793836/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] test performance of nginx using vpp host stack#vpp-hoststack
Hi, What is performance in this case, CPS? If yes, does nginx proxy only towards one IP, hence the need for tcp_max_tw_bucket? You have the option to reduce time wait time in tcp by setting timewait-time in tcp’s startup.conf stanza. I would not recommend reducing it too much as it can lead to corruption of data streams whenever connections cannot be gracefully closed because of lost packets. If you have more IPs vpp could use on the interface vpp towards your server, I’d recommend providing them to tcp via: tcp src-address - Regards, Florin > On Apr 30, 2022, at 4:17 AM, weizhen9...@163.com wrote: > > Hi, > Now I use nginx which uses vpp host stack as a proxy to test the > performance. But I find the performance of nginx using vpp host stack is > lower than nginx using kernel host stack. The reason is that I config the > tcp_max_tw_bucket in kernel host stack. So does the vpp stack support the > setting tcp_max_tw_bucket? If not, can I modify the vpp host stack? > Thanks. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21311): https://lists.fd.io/g/vpp-dev/message/21311 Mute This Topic: https://lists.fd.io/mt/90793836/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] ABF+ACL permit rule behavior ?
Hi,
I will reply myself to close this question and help others in the future.
This is not an issue, this was my misunderstanding of how ABF works with
rules. Any improvement in documentation will be greatly appreciated.
1. set acl-plugin acl permit dst 10.0.0.100/32
create acl with source 0.0.0.0/0 dst 10.0.0.100/32 action permit
2. abf policy add id 0 acl 0 via 10.10.15.1 enp2s0
create policy 0 with acl 0 with rule patch via 10.10.15.1 enp2s0 (interface
can be omnited for L3 routes)
>>> if action is deny => drop packets
>>> if action is permit, compare "ip fib" path (dst 10.0.0.100/32 via
10.10.15.1@enp2s0 ) to configured policy 0 gateway and interface. If match
=> permit. If not match => drop.
3. abf attach ip4 policy 0 loop0
attach policy 0 to the input interface (in my scenario it is loop0)
Thanks
Petr B.
so 30. 4. 2022 v 15:06 odesílatel Petr Boltík via lists.fd.io napsal:
> Hi,
>
> I'm working with combination ABF+ACL plugins, but I have a problem with
> ACL permit rule. ACL action "permit" is ignored and ABF drops packets.
> Please, can someone confirm this is the correct behavior? Thanks
>
> Regards
> Petr B.
>
>
>
> vpp# show version
> vpp v22.06-rc0~378-g6120441f9
>
> ### note:
> vlan 2501@enp3s0(pop1) + loop0(bvi) = bridge domain 192.168.95.100/24
> ping from 192.168.95.17 => 10.0.0.100
>
> 1. add rules:
> set acl-plugin acl permit dst 10.0.0.100/32
> abf policy add id 0 acl 0 via 192.168.95.100 loop0
> abf attach ip4 policy 0 loop0
>
> 2. show
> vpp# show acl-plugin acl
> acl-index 0 count 1 tag {cli}
> 0: ipv4 permit src 0.0.0.0/0 dst 10.0.0.100/32 proto 0 sport
> 0-65535 dport 0-65535
> used in lookup context index: 0
>
> vpp# show abf policy
> abf:[0]: policy:0 acl:0
> path-list:[64] locks:1 flags:shared,no-uRPF, uRPF-list: None
> path:[88] pl-index:64 ip4 weight=1 pref=0 attached-nexthop:
> oper-flags:resolved,
> 192.168.95.100 loop0
> [@0]: arp-ipv4: via 192.168.95.100 loop0
>
> vpp# show abf attach loop0
> ipv4:
> abf-interface-attach: policy:0 priority:0
> [@1]: arp-ipv4: via 192.168.95.100 loop0
>
> 3. show trace
> Packet 4
>
> 00:06:31:315032: dpdk-input
> enp3s0 rx queue 0
> buffer 0x91ad3: current data 0, length 68, buffer-pool 0, ref-count 1,
> trace handle 0x303
> ext-hdr-valid
> PKT MBUF: port 1, nb_segs 1, pkt_len 68
> buf_len 2176, data_len 68, ol_flags 0x182, data_off 128, phys_addr
> 0x5dc6b540
> packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x52c93baa fdir.hi 0x0 fdir.lo 0x52c93baa
> Packet Offload Flags
> PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
> PKT_RX_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
> PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
> PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
> PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
> Packet Types
> RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
> RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
> IP4: 74:4d:28:8d:0d:22 -> 1a:24:b6:07:ca:16 802.1q vlan 2501
> ICMP: 192.168.95.17 -> 10.0.0.100
> tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
> fragment id 0xe913
> ICMP echo_request checksum 0x4637 id 39169
> 00:06:31:315041: ethernet-input
> frame: flags 0x3, hw-if-index 2, sw-if-index 2
> IP4: 74:4d:28:8d:0d:22 -> 1a:24:b6:07:ca:16 802.1q vlan 2501
> 00:06:31:315047: l2-input
> l2-input: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
> [l2-input-vtr l2-learn l2-fwd l2-flood l2-flood ]
> 00:06:31:315049: l2-input-vtr
> l2-input-vtr: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
> data 08 00 45 00 00 32 e9 13 00 00 ff 01
> 00:06:31:315049: l2-learn
> l2-learn: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
> bd_index 1
> 00:06:31:315051: l2-fwd
> l2-fwd: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
> bd_index 1 result [0x7000b, 11] static age-not bvi
> 00:06:31:315052: ip4-input
> ICMP: 192.168.95.17 -> 10.0.0.100
> tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
> fragment id 0xe913
> ICMP echo_request checksum 0x4637 id 39169
> 00:06:31:315054: abf-input-ip4
>next 1 index 28
> 00:06:31:315056: ip4-arp
> ICMP: 192.168.95.17 -> 10.0.0.100
> tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
> fragment id 0xe913
> ICMP echo_request checksum 0x4637 id 39169
> 00:06:31:315064: ip4-drop
> ICMP: 192.168.95.17 -> 10.0.0.100
> tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
> fragment id 0xe913
> ICMP echo_request checksum 0x4637 id 39169
> 00:06:31:315066: error-drop
> rx:loop0
> 00:06:31:315068: drop
> ip4-arp: ARP requests sent
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21310): https://lists.fd.io/g/vpp-dev/message/21310
Mute Thi
[vpp-dev] ABF+ACL permit rule behavior ?
Hi,
I'm working with combination ABF+ACL plugins, but I have a problem with ACL
permit rule. ACL action "permit" is ignored and ABF drops packets. Please,
can someone confirm this is the correct behavior? Thanks
Regards
Petr B.
vpp# show version
vpp v22.06-rc0~378-g6120441f9
### note:
vlan 2501@enp3s0(pop1) + loop0(bvi) = bridge domain 192.168.95.100/24
ping from 192.168.95.17 => 10.0.0.100
1. add rules:
set acl-plugin acl permit dst 10.0.0.100/32
abf policy add id 0 acl 0 via 192.168.95.100 loop0
abf attach ip4 policy 0 loop0
2. show
vpp# show acl-plugin acl
acl-index 0 count 1 tag {cli}
0: ipv4 permit src 0.0.0.0/0 dst 10.0.0.100/32 proto 0 sport
0-65535 dport 0-65535
used in lookup context index: 0
vpp# show abf policy
abf:[0]: policy:0 acl:0
path-list:[64] locks:1 flags:shared,no-uRPF, uRPF-list: None
path:[88] pl-index:64 ip4 weight=1 pref=0 attached-nexthop:
oper-flags:resolved,
192.168.95.100 loop0
[@0]: arp-ipv4: via 192.168.95.100 loop0
vpp# show abf attach loop0
ipv4:
abf-interface-attach: policy:0 priority:0
[@1]: arp-ipv4: via 192.168.95.100 loop0
3. show trace
Packet 4
00:06:31:315032: dpdk-input
enp3s0 rx queue 0
buffer 0x91ad3: current data 0, length 68, buffer-pool 0, ref-count 1,
trace handle 0x303
ext-hdr-valid
PKT MBUF: port 1, nb_segs 1, pkt_len 68
buf_len 2176, data_len 68, ol_flags 0x182, data_off 128, phys_addr
0x5dc6b540
packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x52c93baa fdir.hi 0x0 fdir.lo 0x52c93baa
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_IP_CKSUM_NONE (0x0090) no IP cksum of RX pkt.
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_NONE (0x0108) no L4 cksum of RX pkt.
PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
IP4: 74:4d:28:8d:0d:22 -> 1a:24:b6:07:ca:16 802.1q vlan 2501
ICMP: 192.168.95.17 -> 10.0.0.100
tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
fragment id 0xe913
ICMP echo_request checksum 0x4637 id 39169
00:06:31:315041: ethernet-input
frame: flags 0x3, hw-if-index 2, sw-if-index 2
IP4: 74:4d:28:8d:0d:22 -> 1a:24:b6:07:ca:16 802.1q vlan 2501
00:06:31:315047: l2-input
l2-input: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
[l2-input-vtr l2-learn l2-fwd l2-flood l2-flood ]
00:06:31:315049: l2-input-vtr
l2-input-vtr: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
data 08 00 45 00 00 32 e9 13 00 00 ff 01
00:06:31:315049: l2-learn
l2-learn: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
bd_index 1
00:06:31:315051: l2-fwd
l2-fwd: sw_if_index 4 dst 1a:24:b6:07:ca:16 src 74:4d:28:8d:0d:22
bd_index 1 result [0x7000b, 11] static age-not bvi
00:06:31:315052: ip4-input
ICMP: 192.168.95.17 -> 10.0.0.100
tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
fragment id 0xe913
ICMP echo_request checksum 0x4637 id 39169
00:06:31:315054: abf-input-ip4
next 1 index 28
00:06:31:315056: ip4-arp
ICMP: 192.168.95.17 -> 10.0.0.100
tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
fragment id 0xe913
ICMP echo_request checksum 0x4637 id 39169
00:06:31:315064: ip4-drop
ICMP: 192.168.95.17 -> 10.0.0.100
tos 0x00, ttl 255, length 50, checksum 0xa899 dscp CS0 ecn NON_ECN
fragment id 0xe913
ICMP echo_request checksum 0x4637 id 39169
00:06:31:315066: error-drop
rx:loop0
00:06:31:315068: drop
ip4-arp: ARP requests sent
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21309): https://lists.fd.io/g/vpp-dev/message/21309
Mute This Topic: https://lists.fd.io/mt/90795177/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] test performance of nginx using vpp host stack#vpp-hoststack
Hi, Now I use nginx which uses vpp host stack as a proxy to test the performance. But I find the performance of nginx using vpp host stack is lower than nginx using kernel host stack. The reason is that I config the tcp_max_tw_bucket in kernel host stack. So does the vpp stack support the setting tcp_max_tw_bucket? If not, can I modify the vpp host stack? Thanks. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21308): https://lists.fd.io/g/vpp-dev/message/21308 Mute This Topic: https://lists.fd.io/mt/90793836/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
