[vpp-dev] Question about vlib_next_frame_change_ownership
Hi Dave and all, I'm looking at a buffer trace issue with DPDK IPSEC. It turns out the flag VLIB_FRAME_TRACE is broken in vlib_next_frame_change_ownership(). The node path in my setup is: pg-input -> ip-input -> ip-lookup -> ... -> dkdp-esp-encrypt -> cryptodev -> crypto-input -> ip-lookup -> ... As you can see, the ip-lookup node has the owner node ip-input in the beginning, then owner will be changed to crypto-input shortly. This change causes that we swap the current next_frame with the owner's in vlib_next_frame_change_ownership(). As a result, the VLIB_FRAME_TRACE in next_frame->flag will be overwritten. The fix could be very simple, but I'm wondering why we have to change the ownership of the next_frame? Actually I can observe the ownership is changed back and forth between ip-input and crypto-input for every frame, which leads to performance degradation. However, it looks good to me even that we don’t care the ownership. In this case, ip-lookup will be dispatched by either ip-input or crypto-input, with different next_frame. I guess I must have missed something, appreciate if you can elaborate. Regards, Kingwel -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11976): https://lists.fd.io/g/vpp-dev/message/11976 Mute This Topic: https://lists.fd.io/mt/29430823/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Packet extraction: Policer-classify/Classify-set-interface-l2
Hi, I didn’t find any good documentation on the usage of both Policer-classify and Classify-set-interface-l2. Please share or point me to any documentation on “how to use these two types of classification? And when?”. I have a need to classify received frames based on Destination MAC and/or ether-type in the packet. I am thinking of the following options to achieve it. 1. After looking at the code in vnet/classify/classify_api.c and trace it till l2_input, it looks like they can be used. But not sure if these features are completely working or not, and how to use them. 1. Add some logic somewhere in ethernet_input_inline()->parse_header(), to identify the received frames for a given DMAC and/or ether-type. Please let me know thoughts on the above two options and any inputs on the packet extraction in general. Thanks, Leela sankar -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11975): https://lists.fd.io/g/vpp-dev/message/11975 Mute This Topic: https://lists.fd.io/mt/29429029/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] vpp-verify-master-clang now bionic based
Thanks! -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Ed Kern via Lists.Fd.Io Sent: Tuesday, January 22, 2019 5:47 PM To: vpp-dev Cc: vpp-dev@lists.fd.io Subject: [vpp-dev] vpp-verify-master-clang now bionic based As discussed in the vpp call this morning I have moved this from from running on xenial to bionic. Ran cleanly on the sandbox…but please let me know if anyone sees issues in production. Ed -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11974): https://lists.fd.io/g/vpp-dev/message/11974 Mute This Topic: https://lists.fd.io/mt/29422416/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] vpp-verify-master-clang now bionic based
As discussed in the vpp call this morning I have moved this from from running on xenial to bionic. Ran cleanly on the sandbox…but please let me know if anyone sees issues in production. Ed -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11973): https://lists.fd.io/g/vpp-dev/message/11973 Mute This Topic: https://lists.fd.io/mt/29422416/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] Configuring NAT and Policing together
nat44-out2in node: u32 next0 = SNAT_OUT2IN_NEXT_LOOKUP; <...> vlib_validate_buffer_enqueue_x1 (vm, node, next_index, to_next, n_left_to_next, bi0, next0); whatever you specify in VNET_FEATURE_INIT runs_before is ignored for nat44-out2in, normally when you want continue to nex node in feature arc you use vnet_feature_next(), but this is not possible in NAT (nat44-out2in is not always configured as interface feature, e.g. worker handoff in case of multithreading or combined in-out NAT interface). Matus -Original Message- From: Raj Sent: Tuesday, January 22, 2019 3:22 PM To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Configuring NAT and Policing together On Tue, Jan 22, 2019 at 7:44 PM Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) wrote: > I don't think it is working way you wanted since nat44-out2in goes directly > to ip4-lookup instead of continue in feature arc to ip4-policer-classify. Yes, you were right. My conclusion was premature. I still do not quite understand VNET_FEATURE_INIT to route the traffic the way I want. A sample code fragment would be very helpful. Thanks and Regards, Raj -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11972): https://lists.fd.io/g/vpp-dev/message/11972 Mute This Topic: https://lists.fd.io/mt/29379239/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] Configuring NAT and Policing together
On Tue, Jan 22, 2019 at 7:44 PM Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) wrote: > I don't think it is working way you wanted since nat44-out2in goes directly > to ip4-lookup instead of continue in feature arc to ip4-policer-classify. Yes, you were right. My conclusion was premature. I still do not quite understand VNET_FEATURE_INIT to route the traffic the way I want. A sample code fragment would be very helpful. Thanks and Regards, Raj -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11971): https://lists.fd.io/g/vpp-dev/message/11971 Mute This Topic: https://lists.fd.io/mt/29379239/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] Configuring NAT and Policing together
Hi,
I don't think it is working way you wanted since nat44-out2in goes directly to
ip4-lookup instead of continue in feature arc to ip4-policer-classify.
Matus
-Original Message-
From: Raj
Sent: Tuesday, January 22, 2019 3:00 PM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
This is the patch I have made and looks like its working.
diff --git a/src/plugins/nat/nat.c b/src/plugins/nat/nat.c index
540d3bf8..ac735e9a 100755
--- a/src/plugins/nat/nat.c
+++ b/src/plugins/nat/nat.c
@@ -47,6 +47,7 @@ VNET_FEATURE_INIT (ip4_snat_in2out, static) = {
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
+ .runs_before = VNET_FEATURES ("ip4-policer-classify"),
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"), };
Its just first time hacking on VPP code, so do let me know if this is the right
way or there is a better way.
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11970): https://lists.fd.io/g/vpp-dev/message/11970
Mute This Topic: https://lists.fd.io/mt/29379239/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] Configuring NAT and Policing together
Hi Matus,
This is the patch I have made and looks like its working.
diff --git a/src/plugins/nat/nat.c b/src/plugins/nat/nat.c
index 540d3bf8..ac735e9a 100755
--- a/src/plugins/nat/nat.c
+++ b/src/plugins/nat/nat.c
@@ -47,6 +47,7 @@ VNET_FEATURE_INIT (ip4_snat_in2out, static) = {
VNET_FEATURE_INIT (ip4_snat_out2in, static) = {
.arc_name = "ip4-unicast",
.node_name = "nat44-out2in",
+ .runs_before = VNET_FEATURES ("ip4-policer-classify"),
.runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa",
"ip4-dhcp-client-detect"),
};
Its just first time hacking on VPP code, so do let me know if this is
the right way or there is a better way.
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11969): https://lists.fd.io/g/vpp-dev/message/11969
Mute This Topic: https://lists.fd.io/mt/29379239/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] Configuring NAT and Policing together
comments inline
Matus
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Raj
Sent: Tuesday, January 22, 2019 1:06 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
We were looking to modify the flow so that the south->north path looks
like ip4-input-no-checksum-> ip4-policer-classify -> nat44-in2out ->
ip4-lookup and north->south path should be ip4-input-no-checksum ->
nat44-in2out -> ip4-policer-classify -> ip4-lookup
With your suggested modifications we were able to get the desired flow for
south->north path, but with a small change, by putting "nat44-out2in" in
.runs_after. The code looks like:
.runs_before = VNET_FEATURES ("ipsec-input-ip4","nat44-in2out"),
.runs_after = VNET_FEATURES ("nat44-out2in"),
But in north->south direction ip4-policer-classify node is being skipped.
[mf:] nat44-out2in doesn't continue in feature arc but always goes directly to
ip4-lookup, as I write before NAT can't continue in feature arc using
vnet_feature_next
Also I did not fully understand this statement: "It would be possible to add
additional static graph arc from nat node to ip4-policer-classify and decide on
per-packet basis where to send packet since you don't know at compile time
whether policer is configured on interface.".
[mf:] You can add some code to nat44-out2in node where you packet next node is
chosen, if policer is enabled on interface packet goes to ip4-policer-classify
otherwise as usual to ip4-lookup
Thanks and Regards,
Raj
On Mon, Jan 21, 2019 at 6:04 PM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) wrote:
>
> Hi,
>
> You can use ip4-policer-classify before NAT node. Add nat44-in2out or
> nat44-out2in to ip4_policer_classify runs_before list
> VNET_FEATURE_INIT (ip4_policer_classify, static) = {
> .arc_name = "ip4-unicast",
> .node_name = "ip4-policer-classify",
> .runs_before = VNET_FEATURES ("ipsec4-input-feature",
> "nat44-in2out", "nat44-out2in"), };
>
> NAT code can't continue in feature arc using vnet_feature_next in some cases.
> It would be possible to add additional static graph arc from nat node to
> ip4-policer-classify and decide on per-packet basis where to send packet
> since you don't know at compile time whether policer is configured on
> interface.
>
> Matus
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Raj
> Sent: Monday, January 21, 2019 1:00 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Configuring NAT and Policing together
>
> Hello all,
>
> I am trying to configure NAT and VPP run together, but its not working.
>
> My configuration is as follows:
>
> version: vpp v18.10-release built by root on 41f0552eeae3
>
> Interfaces:
>
> GigabitEthernet1/0/0 (up):
> L3 100.69.1.1/24
> L3 2001:xxx:xxx:600::1/56
> GigabitEthernet1/0/1 (up):
> L3 xxx.79.223.14/29
> L3 2001:xxx:xxx:10d::600/64
>
> Policer config with default route:
>
> configure policer name policy1 cir 500 eir 0 cb 5000 eb 15000 rate
> kbps round closest type 1r3c conform-action transmit exceed-action
> mark-and-transmit AF22 violate-action drop configure policer name
> policy2 cir 750 eir 0 cb 7500 eb 2 rate kbps round closest type
> 1r3c conform-action transmit exceed-action mark-and-transmit AF22
> violate-action drop classify table mask l3 ip4 src classify table mask
> l3 ip4 dst classify session policer-hit-next policy1 exceed-color
> table-index 0 match l3 ip4 src 100.69.1.4 classify session
> policer-hit-next policy2 exceed-color table-index 1 match l3 ip4 dst
> 100.69.1.4 set policer classify interface GigabitEthernet1/0/0
> ip4-table 0 set policer classify interface GigabitEthernet1/0/1
> ip4-table 1 ip route add 0.0.0.0/0 via xxx.79.223.9
> GigabitEthernet1/0/1 ip route add ::/0 via 2001:xxx::10d::1
> GigabitEthernet1/0/1
>
> At this point, if I do a wget at 100.69.1.4 to download from
> xxx.79.223.9, the speed is about 1mbps, but ranging from about 1.5mbps
> to 831kbps
>
> /dev/null 14%[===> ] 75.30M 1.18Mb/s
>
> The packet trace show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:10:21:269382: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:10:21:269383: ip4-input-no-checksum
> 01:10:21:269384: ip4-policer-classify
> 01:10:21:269384: ip4-lookup
> 01:10:21:269384: ip4-rewrite
> 01:10:21:269384: GigabitEthernet1/0/1-output
> 01:10:21:269385: GigabitEthernet1/0/1-tx
>
>
> xxx.79.223.9 -> 100.69.1.4
>
> 01:10:21:268964: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:10:21:268970: ip4-input-no-checksum
> 01:10:21:268973: ip4-policer-classify
> 01:10:21:268974: ip4-lookup
> 01:10:21:268975: ip4-rewrite
> 01:10:21:268976: GigabitEthernet1/0/0-output
> 01:10:21:268976: GigabitEthernet1/0/0-tx
>
> Now adding NAT using the commands:
>
> nat44 add interface address GigabitEthernet1/0/1 set interface nat44
> in GigabitEthernet1/0/0 out GigabitEthernet1/0/1
>
> Policer stops working at this point.
>
>
Re: [vpp-dev] Configuring NAT and Policing together
Hi Matus,
We were looking to modify the flow so that the south->north path looks
like ip4-input-no-checksum-> ip4-policer-classify -> nat44-in2out ->
ip4-lookup and north->south path should be ip4-input-no-checksum ->
nat44-in2out -> ip4-policer-classify -> ip4-lookup
With your suggested modifications we were able to get the desired flow
for south->north path, but with a small change, by putting
"nat44-out2in" in .runs_after. The code looks like:
.runs_before = VNET_FEATURES ("ipsec-input-ip4","nat44-in2out"),
.runs_after = VNET_FEATURES ("nat44-out2in"),
But in north->south direction ip4-policer-classify node is being skipped.
Also I did not fully understand this statement: "It would be possible
to add additional static graph arc from nat node to
ip4-policer-classify and decide on per-packet basis where to send
packet since you don't know at compile time whether policer is
configured on interface.".
Thanks and Regards,
Raj
On Mon, Jan 21, 2019 at 6:04 PM Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco) wrote:
>
> Hi,
>
> You can use ip4-policer-classify before NAT node. Add nat44-in2out or
> nat44-out2in to ip4_policer_classify runs_before list
> VNET_FEATURE_INIT (ip4_policer_classify, static) =
> {
> .arc_name = "ip4-unicast",
> .node_name = "ip4-policer-classify",
> .runs_before = VNET_FEATURES ("ipsec4-input-feature", "nat44-in2out",
> "nat44-out2in"),
> };
>
> NAT code can't continue in feature arc using vnet_feature_next in some cases.
> It would be possible to add additional static graph arc from nat node to
> ip4-policer-classify and decide on per-packet basis where to send packet
> since you don't know at compile time whether policer is configured on
> interface.
>
> Matus
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Raj
> Sent: Monday, January 21, 2019 1:00 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Configuring NAT and Policing together
>
> Hello all,
>
> I am trying to configure NAT and VPP run together, but its not working.
>
> My configuration is as follows:
>
> version: vpp v18.10-release built by root on 41f0552eeae3
>
> Interfaces:
>
> GigabitEthernet1/0/0 (up):
> L3 100.69.1.1/24
> L3 2001:xxx:xxx:600::1/56
> GigabitEthernet1/0/1 (up):
> L3 xxx.79.223.14/29
> L3 2001:xxx:xxx:10d::600/64
>
> Policer config with default route:
>
> configure policer name policy1 cir 500 eir 0 cb 5000 eb 15000 rate kbps round
> closest type 1r3c conform-action transmit exceed-action mark-and-transmit
> AF22 violate-action drop configure policer name policy2 cir 750 eir 0 cb 7500
> eb 2 rate kbps round closest type 1r3c conform-action transmit
> exceed-action mark-and-transmit AF22 violate-action drop classify table mask
> l3 ip4 src classify table mask l3 ip4 dst classify session policer-hit-next
> policy1 exceed-color table-index 0 match l3 ip4 src 100.69.1.4 classify
> session policer-hit-next policy2 exceed-color table-index 1 match l3 ip4 dst
> 100.69.1.4 set policer classify interface GigabitEthernet1/0/0 ip4-table 0
> set policer classify interface GigabitEthernet1/0/1 ip4-table 1 ip route add
> 0.0.0.0/0 via xxx.79.223.9 GigabitEthernet1/0/1 ip route add ::/0 via
> 2001:xxx::10d::1 GigabitEthernet1/0/1
>
> At this point, if I do a wget at 100.69.1.4 to download from xxx.79.223.9,
> the speed is about 1mbps, but ranging from about 1.5mbps to 831kbps
>
> /dev/null 14%[===> ] 75.30M 1.18Mb/s
>
> The packet trace show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:10:21:269382: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:10:21:269383: ip4-input-no-checksum
> 01:10:21:269384: ip4-policer-classify
> 01:10:21:269384: ip4-lookup
> 01:10:21:269384: ip4-rewrite
> 01:10:21:269384: GigabitEthernet1/0/1-output
> 01:10:21:269385: GigabitEthernet1/0/1-tx
>
>
> xxx.79.223.9 -> 100.69.1.4
>
> 01:10:21:268964: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:10:21:268970: ip4-input-no-checksum
> 01:10:21:268973: ip4-policer-classify
> 01:10:21:268974: ip4-lookup
> 01:10:21:268975: ip4-rewrite
> 01:10:21:268976: GigabitEthernet1/0/0-output
> 01:10:21:268976: GigabitEthernet1/0/0-tx
>
> Now adding NAT using the commands:
>
> nat44 add interface address GigabitEthernet1/0/1 set interface nat44 in
> GigabitEthernet1/0/0 out GigabitEthernet1/0/1
>
> Policer stops working at this point.
>
> traces show:
>
> 100.69.1.4 -> xxx.79.223.9
>
> 01:23:19:656284: dpdk-input
> GigabitEthernet1/0/0 rx queue 0
> 01:23:19:656285: ip4-input-no-checksum
> 01:23:19:656285: nat44-in2out
> 01:23:19:656285: ip4-lookup
> 01:23:19:656286: ip4-rewrite
> 01:23:19:656286: GigabitEthernet1/0/1-output
> 01:23:19:656286: GigabitEthernet1/0/1-tx
>
> xxx.79.223.9 -> xxx.79.223.14
>
> 01:23:19:656289: dpdk-input
> GigabitEthernet1/0/1 rx queue 0
> 01:23:19:656290: ip4-input-no-checksum
> 01:23:19:656290: nat44-out2in
> 01:23:19:656290: ip4-lookup
> 01:23:19:656290: ip4-rewrite
> 01:23:19:656290:
