Re: [vpp-dev] Config NAT plugin for with dynamic translations

[david . leitch . vpp]

show interface command at the beginning :

vpp# show interface 
              Name               Idx       State          Counter          
Count     
TenGigabitEthernet21/0/0          5         up       rx packets                 
 6146
                                                     rx bytes                 
1873378
                                                     drops                      
  608
                                                     ip4                        
 6143
                                                     rx-miss                 
14754129
TenGigabitEthernet21/0/1          6         up       rx packets                 
 6146
                                                     rx bytes                 
4797068
                                                     tx packets                 
  692
                                                     tx bytes                  
222109
                                                     drops                      
 1416
                                                     ip4                        
 6143
                                                     rx-miss                 
17712306
                                                     rx-error                   
    7
                                                     tx-error                   
  605
TenGigabitEthernet24/0/0          7         up       rx packets                 
    9
                                                     rx bytes                   
 1323
                                                     drops                      
    5
TenGigabitEthernet24/0/1          8         up       rx packets                 
    9
                                                     rx bytes                   
 1323
                                                     drops                      
    5
                                                     rx-error                   
    2
TenGigabitEthernet4/0/0           1         up       rx packets                 
 6147
                                                     rx bytes                 
1565056
                                                     drops                      
 1117
                                                     ip4                        
 6144
                                                     rx-miss                  
5757037
TenGigabitEthernet4/0/1           2         up       rx packets                 
 6147
                                                     rx bytes                 
5017096
                                                     tx packets                 
 1021
                                                     tx bytes                  
256661
                                                     drops                      
 2520
                                                     ip4                        
 6144
                                                     rx-miss                   
327524
                                                     tx-error                   
 1114
TenGigabitEthernet7/0/0           3         up       rx packets                 
 6147
                                                     rx bytes                 
1731624
                                                     drops                      
  736
                                                     ip4                        
 6144
                                                     rx-miss                  
5262760
                                                     rx-error                   
    3
TenGigabitEthernet7/0/1           4         up       rx packets                 
 6147
                                                     rx bytes                 
4517837
                                                     tx packets                 
  720
                                                     tx bytes                  
246343
                                                     drops                      
 1681
                                                     ip4                        
 6144
                                                     rx-miss                   
327272
                                                     tx-error                   
  733
local0                            0        down      
vpp# 

after a few second :

vpp# 
vpp# clear interfaces
vpp# 
vpp# show interface  
              Name               Idx       State          Counter          
Count     
TenGigabitEthernet21/0/0          5         up       
TenGigabitEthernet21/0/1          6         up       
TenGigabitEthernet24/0/0          7         up       
TenGigabitEthernet24/0/1          8         up       
TenGigabitEthernet4/0/0           1         up       
TenGigabitEthernet4/0/1           2         up       
TenGigabitEthernet7/0/0           3         up       
TenGigabitEthernet7/0/1           4         up       
local0        

Re: [vpp-dev] Config NAT plugin for with dynamic translations

[Ole Troan]

David,

Can you enable trace “trace add dpdk-input 10” and send a few packets, then do 
“show trace”?

Cheers,
Ole

> On 18 Dec 2018, at 09:05, david.leitch@gmail.com wrote:
> 
> show interface command at the beginning :
> 
> vpp# show interface 
>   Name   Idx   State  Counter  
> Count 
> TenGigabitEthernet21/0/0  5 up   rx packets   
>6146
>  rx bytes 
> 1873378
>  drops
> 608
>  ip4  
>6143
>  rx-miss 
> 14754129
> TenGigabitEthernet21/0/1  6 up   rx packets   
>6146
>  rx bytes 
> 4797068
>  tx packets   
> 692
>  tx bytes 
>  222109
>  drops
>1416
>  ip4  
>6143
>  rx-miss 
> 17712306
>  rx-error 
>   7
>  tx-error 
> 605
> TenGigabitEthernet24/0/0  7 up   rx packets   
>   9
>  rx bytes 
>1323
>  drops
>   5
> TenGigabitEthernet24/0/1  8 up   rx packets   
>   9
>  rx bytes 
>1323
>  drops
>   5
>  rx-error 
>   2
> TenGigabitEthernet4/0/0   1 up   rx packets   
>6147
>  rx bytes 
> 1565056
>  drops
>1117
>  ip4  
>6144
>  rx-miss  
> 5757037
> TenGigabitEthernet4/0/1   2 up   rx packets   
>6147
>  rx bytes 
> 5017096
>  tx packets   
>1021
>  tx bytes 
>  256661
>  drops
>2520
>  ip4  
>6144
>  rx-miss  
>  327524
>  tx-error 
>1114
> TenGigabitEthernet7/0/0   3 up   rx packets   
>6147
>  rx bytes 
> 1731624
>  drops
> 736
>  ip4  
>6144
>  rx-miss  
> 5262760
>  rx-error 
>   3
> TenGigabitEthernet7/0/1   4 up   rx packets   
>6147
>  rx bytes 
> 4517837
>  tx packets   
> 720
>  tx bytes 
>  246343
>  drops
>1681
>  ip4  
>6144
>  rx-miss  
>  327272
>  tx-error 
> 733
> local00down  
> vpp# 
> 
> after a few second :
> 
> 
> vpp# 
> vpp# clear interfaces
> vpp# 
> vpp# show interface  
>   Name   Idx   State  Counter  
> Count 
> TenGigabitEthernet21/0/0  5 

Re: [vpp-dev] Config NAT plugin for with dynamic translations

[david . leitch . vpp]

# vpp show trace
[...]
--- Start of thread 16 vpp_wk_15 ---
Packet 1
 
00:00:02:897486: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 15
  buffer 0x25507a1: current data 14, length 46, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
                    ext-hdr-valid 
                    l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14 
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x182, data_off 128, phys_addr 
0xaf01e8c0
    packet_type 0x111 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    Packet Offload Flags
      PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
      RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
      RTE_PTYPE_L4_TCP (0x0100) TCP packet
  IP4: 38:ea:a7:16:d0:f4 -> 00:1b:21:bc:10:42
  TCP: 16.4.13.55 -> 46.4.13.55
    tos 0x00, ttl 128, length 40, checksum 0x6961
    fragment id 0x78f9
  TCP: 12021 -> 80
    seq. 0x17f0b4e8 ack 0x17f15fe3
    flags 0x10 ACK, tcp header: 20 bytes
    window 32768, checksum 0x636c
00:00:05:215972: ip4-input-no-checksum
  TCP: 16.4.13.55 -> 46.4.13.55
    tos 0x00, ttl 128, length 40, checksum 0x6961
    fragment id 0x78f9
  TCP: 12021 -> 80
    seq. 0x17f0b4e8 ack 0x17f15fe3
    flags 0x10 ACK, tcp header: 20 bytes
    window 32768, checksum 0x636c
00:00:05:216816: nat44-in2out-worker-handoff
  NAT44_IN2OUT_WORKER_HANDOFF: next worker 9
 
Packet 2
 
00:00:02:897486: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 15
  buffer 0x255077a: current data 14, length 46, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
                    ext-hdr-valid 
                    l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14 
  PKT MBUF: port 0, nb_segs 1, pkt_len 60
    buf_len 2176, data_len 60, ol_flags 0x182, data_off 128, phys_addr 
0xaf01df00
    packet_type 0x111 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    Packet Offload Flags
      PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
      RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
      RTE_PTYPE_L4_TCP (0x0100) TCP packet
  IP4: 38:ea:a7:16:d0:f4 -> 00:1b:21:bc:10:42
  TCP: 16.3.251.132 -> 46.3.251.132
    tos 0x00, ttl 128, length 40, checksum 0x8c6c
    fragment id 0x7954
  TCP: 55312 -> 80
    seq. 0x181a46d4 ack 0x181afd8e
    flags 0x10 ACK, tcp header: 20 bytes
    window 32768, checksum 0xadcc
00:00:05:215972: ip4-input-no-checksum
  TCP: 16.3.251.132 -> 46.3.251.132
    tos 0x00, ttl 128, length 40, checksum 0x8c6c
    fragment id 0x7954
  TCP: 55312 -> 80
    seq. 0x181a46d4 ack 0x181afd8e
    flags 0x10 ACK, tcp header: 20 bytes
    window 32768, checksum 0xadcc
00:00:05:216816: nat44-in2out-worker-handoff
  NAT44_IN2OUT_WORKER_HANDOFF: next worker 19
 
Packet 3
 
00:00:02:897486: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 15
  buffer 0x2550753: current data 14, length 1500, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x2
                    ext-hdr-valid 
                    l4-cksum-computed l4-cksum-correct l2-hdr-offset 0 
l3-hdr-offset 14 
  PKT MBUF: port 0, nb_segs 1, pkt_len 1514
    buf_len 2176, data_len 1514, ol_flags 0x182, data_off 128, phys_addr 
0xaf01d540
    packet_type 0x111 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
    Packet Offload Flags
      PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
      PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
      PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
    Packet Types
      RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
      RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
      RTE_PTYPE_L4_TCP (0x0100) TCP packet
  IP4: 38:ea:a7:16:d0:f4 -> 00:1b:21:bc:10:42
  TCP: 16.4.13.67 -> 46.4.13.67
    tos 0x00, ttl 128, length 1500, checksum 0x6382
    fragment id 0x790c
  TCP: 24255 -> 80
    seq. 0x17fa1ec0 ack 0x17facb57
    flags 0x18 PSH ACK, tcp header: 20 bytes
    window 32768, checksum 0x3c02
00:00:05:215972: ip4-input-no-checksum
  TCP: 16.4.13.67 -> 46.4.13.67
    tos 0x00, ttl 128, length 1500, checksum 0x6382
    fragment id 0x790c
  TCP: 24255 -> 80
    seq. 0x17fa1ec0 ack 0x17facb57
    flags 0x18 PSH ACK, tcp header: 20 bytes
    window 32768, checksum 0x3c02
00:00:05:216816: nat44-in2out-worker-handoff
  NAT44_IN2OUT_WORKER_HANDOFF: next worker 37
 
Packet 4
 
00:00:02:897486: dpdk-input
  TenGigabitEthernet4/0/0 rx queue 15
  buffer 0x255072c: current data 14, length 292, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x3
                    ext-hdr-valid 
                    l4-cksum-computed 

Re: [vpp-dev] Config NAT plugin for with dynamic translations

[david . leitch . vpp]

vpp# show interface rx-placement 
Thread 1 (vpp_wk_0):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 0 (polling)
    TenGigabitEthernet4/0/1 queue 0 (polling)
    TenGigabitEthernet7/0/0 queue 0 (polling)
    TenGigabitEthernet7/0/1 queue 0 (polling)
    TenGigabitEthernet21/0/0 queue 0 (polling)
    TenGigabitEthernet21/0/1 queue 0 (polling)
    TenGigabitEthernet24/0/0 queue 0 (polling)
    TenGigabitEthernet24/0/1 queue 0 (polling)
Thread 2 (vpp_wk_1):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 1 (polling)
    TenGigabitEthernet4/0/1 queue 1 (polling)
    TenGigabitEthernet7/0/0 queue 1 (polling)
    TenGigabitEthernet7/0/1 queue 1 (polling)
    TenGigabitEthernet21/0/0 queue 1 (polling)
    TenGigabitEthernet21/0/1 queue 1 (polling)
    TenGigabitEthernet24/0/0 queue 1 (polling)
    TenGigabitEthernet24/0/1 queue 1 (polling)
Thread 3 (vpp_wk_2):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 2 (polling)
    TenGigabitEthernet4/0/1 queue 2 (polling)
    TenGigabitEthernet7/0/0 queue 2 (polling)
    TenGigabitEthernet7/0/1 queue 2 (polling)
    TenGigabitEthernet21/0/0 queue 2 (polling)
    TenGigabitEthernet21/0/1 queue 2 (polling)
    TenGigabitEthernet24/0/0 queue 2 (polling)
    TenGigabitEthernet24/0/1 queue 2 (polling)
[...]
Thread 38 (vpp_wk_37):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 37 (polling)
    TenGigabitEthernet4/0/1 queue 37 (polling)
    TenGigabitEthernet7/0/0 queue 37 (polling)
    TenGigabitEthernet7/0/1 queue 37 (polling)
    TenGigabitEthernet21/0/0 queue 37 (polling)
    TenGigabitEthernet21/0/1 queue 37 (polling)
    TenGigabitEthernet24/0/0 queue 37 (polling)
    TenGigabitEthernet24/0/1 queue 37 (polling)
Thread 39 (vpp_wk_38):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 38 (polling)
    TenGigabitEthernet4/0/1 queue 38 (polling)
    TenGigabitEthernet7/0/0 queue 38 (polling)
    TenGigabitEthernet7/0/1 queue 38 (polling)
    TenGigabitEthernet21/0/0 queue 38 (polling)
    TenGigabitEthernet21/0/1 queue 38 (polling)
    TenGigabitEthernet24/0/0 queue 38 (polling)
    TenGigabitEthernet24/0/1 queue 38 (polling)
Thread 40 (vpp_wk_39):
  node dpdk-input:
    TenGigabitEthernet4/0/0 queue 39 (polling)
    TenGigabitEthernet4/0/1 queue 39 (polling)
    TenGigabitEthernet7/0/0 queue 39 (polling)
    TenGigabitEthernet7/0/1 queue 39 (polling)
    TenGigabitEthernet21/0/0 queue 39 (polling)
    TenGigabitEthernet21/0/1 queue 39 (polling)
    TenGigabitEthernet24/0/0 queue 39 (polling)
    TenGigabitEthernet24/0/1 queue 39 (polling)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11656): https://lists.fd.io/g/vpp-dev/message/11656
Mute This Topic: https://lists.fd.io/mt/28790237/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] Config NAT plugin for with dynamic translations

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

What is your VPP version?

Matus


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Tuesday, December 18, 2018 9:26 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Config NAT plugin for with dynamic translations

vpp# show interface rx-placement
Thread 1 (vpp_wk_0):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 0 (polling)
TenGigabitEthernet4/0/1 queue 0 (polling)
TenGigabitEthernet7/0/0 queue 0 (polling)
TenGigabitEthernet7/0/1 queue 0 (polling)
TenGigabitEthernet21/0/0 queue 0 (polling)
TenGigabitEthernet21/0/1 queue 0 (polling)
TenGigabitEthernet24/0/0 queue 0 (polling)
TenGigabitEthernet24/0/1 queue 0 (polling)
Thread 2 (vpp_wk_1):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 1 (polling)
TenGigabitEthernet4/0/1 queue 1 (polling)
TenGigabitEthernet7/0/0 queue 1 (polling)
TenGigabitEthernet7/0/1 queue 1 (polling)
TenGigabitEthernet21/0/0 queue 1 (polling)
TenGigabitEthernet21/0/1 queue 1 (polling)
TenGigabitEthernet24/0/0 queue 1 (polling)
TenGigabitEthernet24/0/1 queue 1 (polling)
Thread 3 (vpp_wk_2):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 2 (polling)
TenGigabitEthernet4/0/1 queue 2 (polling)
TenGigabitEthernet7/0/0 queue 2 (polling)
TenGigabitEthernet7/0/1 queue 2 (polling)
TenGigabitEthernet21/0/0 queue 2 (polling)
TenGigabitEthernet21/0/1 queue 2 (polling)
TenGigabitEthernet24/0/0 queue 2 (polling)
TenGigabitEthernet24/0/1 queue 2 (polling)
[...]
Thread 38 (vpp_wk_37):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 37 (polling)
TenGigabitEthernet4/0/1 queue 37 (polling)
TenGigabitEthernet7/0/0 queue 37 (polling)
TenGigabitEthernet7/0/1 queue 37 (polling)
TenGigabitEthernet21/0/0 queue 37 (polling)
TenGigabitEthernet21/0/1 queue 37 (polling)
TenGigabitEthernet24/0/0 queue 37 (polling)
TenGigabitEthernet24/0/1 queue 37 (polling)
Thread 39 (vpp_wk_38):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 38 (polling)
TenGigabitEthernet4/0/1 queue 38 (polling)
TenGigabitEthernet7/0/0 queue 38 (polling)
TenGigabitEthernet7/0/1 queue 38 (polling)
TenGigabitEthernet21/0/0 queue 38 (polling)
TenGigabitEthernet21/0/1 queue 38 (polling)
TenGigabitEthernet24/0/0 queue 38 (polling)
TenGigabitEthernet24/0/1 queue 38 (polling)
Thread 40 (vpp_wk_39):
  node dpdk-input:
TenGigabitEthernet4/0/0 queue 39 (polling)
TenGigabitEthernet4/0/1 queue 39 (polling)
TenGigabitEthernet7/0/0 queue 39 (polling)
TenGigabitEthernet7/0/1 queue 39 (polling)
TenGigabitEthernet21/0/0 queue 39 (polling)
TenGigabitEthernet21/0/1 queue 39 (polling)
TenGigabitEthernet24/0/0 queue 39 (polling)
TenGigabitEthernet24/0/1 queue 39 (polling)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11657): https://lists.fd.io/g/vpp-dev/message/11657
Mute This Topic: https://lists.fd.io/mt/28790237/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] Config NAT plugin for with dynamic translations

[david . leitch . vpp]

I used VPP18.04
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11658): https://lists.fd.io/g/vpp-dev/message/11658
Mute This Topic: https://lists.fd.io/mt/28790237/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] Config NAT plugin for with dynamic translations

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

Please try to use 18.10

Matus


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Tuesday, December 18, 2018 9:43 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Config NAT plugin for with dynamic translations

I used VPP18.04
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11659): https://lists.fd.io/g/vpp-dev/message/11659
Mute This Topic: https://lists.fd.io/mt/28790237/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] Build/rebuild problems (adding dpdk support)

[Brian Dickson]

On Mon, Dec 17, 2018 at 11:51 PM Marco Varlese  wrote:

> Hi Brian,
>
> On Mon, 2018-12-17 at 20:19 -0800, Brian Dickson wrote:
>
> Hi, VPP folks,
>
> I am trying to add in support for a new card/driver.
>
> The info on the DPDK website says the drivers I have should work fine.
>
> Thus, the only issue is adding in the correct manufacturer/device IDs into
> the init.c file:
>
> src/plugins/dpdk/device/init.c
>
>
> I edit the file (one-line change), put it back into the .tar.xz file, put
> it where it should be being picked up (in build-root or so I believe), and
> it gets blown away.
>
>
> It always seems to want to pull everything from git regardless of the
> presence of the right tar.xz file in build-root, pointed to by the
> vpp-latest symbolic link.
>
>
> I am using "make pkg-rpm" as the command to rebuild things from the main
> vpp source root (parent of build-root).
>
>
> What am I doing wrong?
>
>
> Where should I be rebuilding this?
>
> If it's something that small I would suggest to follow the same approach
> used today: add a patch to the VPP repo to patch DPDK tarball after it has
> been downloaded.
>

The problem (or so it seems to me) is that the thing needing patched is
part of the vpp plugins, not dpdk's tarball itself. The patch stuff seems
specific to stuff in external (e.g. dpdk), and I couldn't figure out how to
do something similar to vpp itself.


> See under "/build/external/patches/" there are various sub-folders for the
> different DPDK versions.
> The file build/external/packages.mk already takes care of navigating the
> various directories to apply the patch files so it's a matter of having the
> new patch in the directory as mentioned above.
> Now, I am not sure whether your patch is already on its ways to DPDK
> upstream but it would be really a good idea to do that.
>

No, it's not dpdk that needs the patch, it is vpp's plugins (specifically
the plugin for dpdk), which needs the card support added.
Specifically plugins/dpdk/device/init.c
(That's where specific mfg:device combos are validated.)

BTW, I think I did manage to build something that accepted the card, but
there still seems to be something that dpdk itself doesn't like about the
card/driver.

Here's what I did, literally: "cd extras/rpm; make" - which builds a new
set of *.rpm files and puts them in build-root, and then I did a "yum
reinstall *.rpm" to those.
I no longer get the "dpdk: Unsupported PCI device 0x1077:0x1634 found at PCI
address :65:00.1" messages.
However, after starting up vpp, I get "kernel: qede :65:00.0: Ending
qede_remove successfully" (for both of the PCI devices).

I might have to rebuild dpdk for the card, as well as the vpp plugin.

The card in question is a Cavium (nee Qlogic, now Marvell) FastLinq 45000
series, with mfg:device of 0x1077:0x1634

The driver is qede:
 qede 65:00.00: Storm FW 8.37.5.0, Management FW 8.35.41.0 [MBI 8.35.21]
[ens2f0]

The dpdk site says this should be good for dpdk support.

Any suggestions (e.g. dpdk version, plus build instructions for the vpp
plugins change for dpdk) welcome.

Thanks in advance,
Brian

>
> What command should I use?
>
> Or what make target?
>
> In what directory?
>
> I suppose all the three questions above are answered in the 1st point.
>
>
> Thanks in advance.
>
>
> Brian
>
> Best,
> Marco
>
>
> P.S. I already spent a lot of time chasing a red herring. Does someone
> want to explain to me the purpose of the "sed -e s/-/_/" in
> extras/rpm/Makefile, full line:
>
> RELEASE=$(shell echo $(BASENAME) | cut -f3- -d- | sed -e s/-/_/g)
>
>
> It seems really out of place, and leads to lots of difficulty in tracking
> down the place where something that looks like "foo-bar-blech" becomes
> "foo-bar_blech", for no obvious reason.
>
> -=-=-=-=-=-=-=-=-=-=-=-
>
> Links: You receive all messages sent to this group.
>
>
> View/Reply Online (#11641):
>
> https://lists.fd.io/g/vpp-dev/message/11641
>
>
> Mute This Topic:
>
> https://lists.fd.io/mt/28789545/675056
>
>
> Group Owner:
>
> vpp-dev+ow...@lists.fd.io
>
>
> Unsubscribe:
>
> https://lists.fd.io/g/vpp-dev/unsub
>
>   [
>
> mvarl...@suse.de
>
> ]
>
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11660): https://lists.fd.io/g/vpp-dev/message/11660
Mute This Topic: https://lists.fd.io/mt/28789545/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] Sanity check re: NAT for same-service mapping

[JB]

Hi Matus,

There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.

Sincerely,
John

Sent from my phone




On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:


Hi,

Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44

Matus

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of JB
Sent: Tuesday, December 18, 2018 12:02 AM
To: Ole Troan
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Ole,

Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.
Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.

That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.

Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.

RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787
Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the provider to be strict on their internal allocation of RFC6598 
(CGNAT) address space otherwise they'll have to allocate large networks that 
would be mostly unused, and very wasteful computationally when traversing the 
NAT allocations.

Kind regards,

John

From: Ole Troan
Sent: Monday, December 17, 2018 10:26 PM
To: John Biscevic
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

> This might be best answered by Matus since it regards NAT, but I'll throw it 
> out there for the whole group.
>
> The endpoint-dependent feature of the NAT plugin - Endpoint address AND port 
> dependent I presume from the 6-tuple description of it - allows us to map the 
> same internal source IP and port to the same external IP when targeting a 
> certain past destination IP AND port, correct?
> My concern is more of the situations where services initially create a 
> connection to one endpoint address, and then create another session to 
> another endpoint address, expecting the same source address to match the 
> client.
>
> Client opens a connection to endpoint X using external IP A, which proceeds 
> to instruct client to open a session to endpoint Y, both endpoints share the 
> same backend and expect the client to have IP A but since it's a new session 
> and we're doing dynamic NAT, the client ends up with external IP B, breaking 
> the chain. Many services depend on this.
>
> The idea is that when a new NAT source IP is seen, that we reserve a certain 
> number of internal ports for that IP to the same number of external ports on 
> a single IP, so all connections originating from that NAT source IP will 
> always have the same external IP, thus allowing for endpoint services to not 
> lose track of client due to IP mismatch, which breaks service.

Yes, and this is the reason why the IETF recommendeds against it, and 
recommends the use of endpoint independent mapping.
In one sense, us at your peril, in the other sense, given that we've run out of 
Ipv4 addresses, that will have consequences for applications too.

Address and port dependent mapping obviously has the great benefit of using the 
address/port space efficiently.
One option we discussed, which I'm happy to encourage patches for, is to make 
the NAT mode, NAT traversal

Re: [vpp-dev] Sanity check re: NAT for same-service mapping

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone



On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.



RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787

Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the provider to be strict on their internal allocation of RFC6598 
(CGNAT) address space otherwise they'll have to allocate large networks that 
would be mostly unused, and very wasteful computationally when traversing the 
NAT allocations.



Kind regards,



John



From: Ole Troan

Sent: Monday, December 17, 2018 10:26 PM

To: John Biscevic

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



> This might be best answered by Matus since it regards NAT, but I'll throw it 
> out there for the whole group.

>

> The endpoint-dependent feature of the NAT plugin - Endpoint address AND port 
> dependent I presume from the 6-tuple description of it - allows us to map the 
> same internal source IP and port to the same external IP when targeting a 
> certain past destination IP AND port, correct?

> My concern is more of the situations where services initially create a 
> connection to one endpoint address, and then create another session to 
> another endpoint address, expecting the same source address to match the 
> client.

>

> Client opens a connection to endpoint X using external IP A, which proceeds 
> to instruct client to open a session to endpoint Y, both endpoints share the 
> same backend and expect the client to have IP A but since it's a new session 
> and we're doing dynamic NAT, the client ends up with external IP B, breaking 
> the chain. Many services depend on this.

>

> The idea is that when a new NAT source IP is seen, that we reserve a certain 
> number of internal ports for that IP to the same number of external ports on 
> a single IP, so all connections originating from that NAT source IP will 
> always have the same external IP, thus allowing for endpoint services to not 
> lose track of client due to IP mismatch, which breaks service.



Yes, and this is the reason why the IETF recommendeds against it, and 
re

[vpp-dev] vPP handoff discussion

[Kingwel Xie]

Hi Damjan,

My fault that I should have made it clear. What I want to say is that I wonder 
if the existing handoff mechanism needs some improvement. Using a ring seems to 
be simpler, and better from performance perspective. Even more, I think it 
could help with the packet drop issue due to bigger and more flexible ring size.

Sorry I changed the subject, it doesn’t strictly follow the original one any 
more.

Regards,
Kingwel

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Tuesday, December 18, 2018 3:12 PM
To: Kingwel Xie 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:


Dear Kingwei,

I don't think VPP handoff is right solution for this problem. It can be solved 
in much simpler way.
We can simply have simple ring by worker tthread where new packets pending 
encryption/decryption are enqueued.
Then we can have input node which runs on all threads and  polls those rings. 
When there is new packet on the ring
that input node simply uses atomic compare and swap to declare that it is 
responsible for enc/dec of specific packet.
when encryption is completed, owning thread enqueues packets to the next node 
in preserved packet order...

Does this make sense?

--
Damjan


On 18 Dec 2018, at 03:22, Kingwel Xie 
mailto:kingwel@ericsson.com>> wrote:

Hi Damjan,

Yes, agree with you.

Here I got a thought about handoff mechanism in vPP. If looking into the DPDK 
crypto scheduler, you will find out that it heavily depends on DPDK rings, for 
buffer delivery among CPU cores and even for the packet reordering. Therefore, 
something comes to my mind, why can’t we use a ring for handoff?

First, as you know, the existing handoff is somewhat limited – the queue size 
is 32 by default, very little, and each queue item is a vector with up to 256 
buffer indices, but each vector might only have very few buffers when system is 
not so high. It is not efficient as I can see, and system might drop packets 
due to queue full.

Second, I think the technique used in vlib_get_frame_queue_elt might be slower 
or less efficient than compare-swap in dpdk ring.

Even more, this 2-dimension data structure also brings up complexity when it 
comes to coding. F.g., handoff-dispatch needs to consolidate buffers into a 
size 128 vector.

In general, I’d believe a ring-like mechanism probably makes handoff easier. I 
understand the ring requires compare-swap instruction which definitely 
introduces performance penalty, but on the other hand, handoff itself always 
introduces massive data cache misses, even worse than compare-swap. However, 
handoff  is always worthwhile in some case even there is penalty.

Appreciate you can share your opinion.

Regards,
Kingwel





From: Damjan Marion mailto:dmar...@me.com>>
Sent: Tuesday, December 18, 2018 1:03 AM
To: Kingwel Xie mailto:kingwel@ericsson.com>>
Cc: Gonsalves, Avinash (Nokia - IN/Bangalore) 
mailto:avinash.gonsal...@nokia.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:


Hi Kingwei,

I agree this is useful feature, that's why i believe it should be implemented 
as native code instead of relying on external implementation which is from our 
perspective sub-optimal
due to dpdk dependency, time spent on buffer metadata conversion, etc..

--
Damjan



On 17 Dec 2018, at 15:19, Kingwel Xie 
mailto:kingwel@ericsson.com>> wrote:

Hi Avinash,

I happened to look at the patch recently. To my understanding, it is valuable, 
cool stuff, as it allows offloading crypto to other cpu cores. Therefore, more 
throughput can be archieved. A question, you patched the dpdk ring to mp and 
mc, why not mp and sc?

Hi Damjan,

I guess the native ipsec mb plugin doesnot support offloading? Or maybe we can 
do a handoff, but anyhow we can not handoff one ipsec session to multi cores. 
Am I right?

Regards,
Kingwel

 原始邮件 
主题： Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:
来自： "Damjan Marion via Lists.Fd.Io" 
mailto:dmarion=me@lists.fd.io>>
发至： 2018年12月17日 下午4:45
抄送： "Gonsalves, Avinash (Nokia - IN/Bangalore)" 
mailto:avinash.gonsal...@nokia.com>>

Dear Avinash,

First, please use public mailing list for such requests, instead of unicasting 
people.

Regarding your patch, I don't feel comfortable to code review it, as I'm not 
familiar with dpdk crypto scheduler.

Personally, I believe such things should be implemented as native VPP code 
instead. We are already in process of moving from
DPDK AES-NI into native code (still dependant on ipsec MB lib) so this stuff 
will not be much usable in this form anyway.

But this is just my opinion, will leave it to others...

--
Damjan



On 13 Dec 2018, at 05:52, Gonsalves, Avinash (Nokia - IN/Bangalore) 
mailto:avinash.gonsal...@nokia.com>> wrote:

Hi Dave, Damjan,

This was verified earlier, but didn’t get integrated. Could you please have a 
look?

Thanks,
Avinash

-=-=-=-=

Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:

[Kingwel Xie]

Hi Avinash,

My question about the MP/MC ring flag that you made a patch to DPDK, any 
comments?

I’d like them to be MP/SC, as we always have only one consumer.

Regards,
Kingwel

From: vpp-dev@lists.fd.io  On Behalf Of Gonsalves, Avinash 
(Nokia - IN/Bangalore)
Sent: Tuesday, December 18, 2018 3:33 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:


Hi Damjan, Kingwel,

Most of the changes in the dpdk plugin is generic and works for other crypto 
devices as well, so can we have this patch integrated while the design with VPP 
Native support is being discussed?

The DPDK patch has been forwarded separately to the DPDK community.

Please find scaling numbers for a sample IMIX profile:

[cid:image001.jpg@01D496F5.65528DD0]




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11664): https://lists.fd.io/g/vpp-dev/message/11664
Mute This Topic: https://lists.fd.io/mt/28779969/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 handoff discussion

[Damjan Marion via Lists.Fd.Io]

Possibly, do you have any numbers to support your statement?

-- 
Damjan

> On 18 Dec 2018, at 10:14, Kingwel Xie  wrote:
> 
> Hi Damjan,
>  
> My fault that I should have made it clear. What I want to say is that I 
> wonder if the existing handoff mechanism needs some improvement. Using a ring 
> seems to be simpler, and better from performance perspective. Even more, I 
> think it could help with the packet drop issue due to bigger and more 
> flexible ring size.
>  
> Sorry I changed the subject, it doesn’t strictly follow the original one any 
> more.
>  
> Regards,
> Kingwel
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Damjan Marion via Lists.Fd.Io
> Sent: Tuesday, December 18, 2018 3:12 PM
> To: Kingwel Xie mailto:kingwel@ericsson.com>>
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/: 
> 
>  
>  
> Dear Kingwei,
>  
> I don't think VPP handoff is right solution for this problem. It can be 
> solved in much simpler way.
> We can simply have simple ring by worker tthread where new packets pending 
> encryption/decryption are enqueued.
> Then we can have input node which runs on all threads and  polls those rings. 
> When there is new packet on the ring
> that input node simply uses atomic compare and swap to declare that it is 
> responsible for enc/dec of specific packet.
> when encryption is completed, owning thread enqueues packets to the next node 
> in preserved packet order...
>  
> Does this make sense?
>  
> -- 
> Damjan
> 
> 
> On 18 Dec 2018, at 03:22, Kingwel Xie  > wrote:
>  
> Hi Damjan,
>  
> Yes, agree with you. 
>  
> Here I got a thought about handoff mechanism in vPP. If looking into the DPDK 
> crypto scheduler, you will find out that it heavily depends on DPDK rings, 
> for buffer delivery among CPU cores and even for the packet reordering. 
> Therefore, something comes to my mind, why can’t we use a ring for handoff? 
>  
> First, as you know, the existing handoff is somewhat limited – the queue size 
> is 32 by default, very little, and each queue item is a vector with up to 256 
> buffer indices, but each vector might only have very few buffers when system 
> is not so high. It is not efficient as I can see, and system might drop 
> packets due to queue full.
>  
> Second, I think the technique used in vlib_get_frame_queue_elt might be 
> slower or less efficient than compare-swap in dpdk ring.
>  
> Even more, this 2-dimension data structure also brings up complexity when it 
> comes to coding. F.g., handoff-dispatch needs to consolidate buffers into a 
> size 128 vector.
>  
> In general, I’d believe a ring-like mechanism probably makes handoff easier. 
> I understand the ring requires compare-swap instruction which definitely 
> introduces performance penalty, but on the other hand, handoff itself always 
> introduces massive data cache misses, even worse than compare-swap. However, 
> handoff  is always worthwhile in some case even there is penalty.
>  
> Appreciate you can share your opinion.
>  
> Regards,
> Kingwel
>  
>  
>  
>  
>  
> From: Damjan Marion mailto:dmar...@me.com>> 
> Sent: Tuesday, December 18, 2018 1:03 AM
> To: Kingwel Xie mailto:kingwel@ericsson.com>>
> Cc: Gonsalves, Avinash (Nokia - IN/Bangalore)  >; vpp-dev@lists.fd.io 
> 
> Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/: 
> 
>  
>  
> Hi Kingwei,
>  
> I agree this is useful feature, that's why i believe it should be implemented 
> as native code instead of relying on external implementation which is from 
> our perspective sub-optimal
> due to dpdk dependency, time spent on buffer metadata conversion, etc..
>  
> -- 
> Damjan
> 
> 
> 
> On 17 Dec 2018, at 15:19, Kingwel Xie  > wrote:
>  
> Hi Avinash,
>  
> I happened to look at the patch recently. To my understanding, it is 
> valuable, cool stuff, as it allows offloading crypto to other cpu cores. 
> Therefore, more throughput can be archieved. A question, you patched the dpdk 
> ring to mp and mc, why not mp and sc?
>  
> Hi Damjan,
>  
> I guess the native ipsec mb plugin doesnot support offloading? Or maybe we 
> can do a handoff, but anyhow we can not handoff one ipsec session to multi 
> cores. Am I right?
>  
> Regards,
> Kingwel
>  
> 
>  原始邮件 
> 主题： Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/: 
> 
> 来自： "Damjan Marion via Lists.Fd.Io"  >
> 发至： 2018年12月17日 下午4:45
> 抄送： "Gonsalves, Avinash (Nokia - IN/Bangalore)"  >
>  
> Dear Avinash, 
>  
> First, please use public mailing list for such requests, instead of 
> unicasting people.
>  
> Reg

Re: [vpp-dev] Config NAT plugin for with dynamic translations

[david . leitch . vpp]

vpp 18.04 NAT plugin has bug or it does not work ???
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11666): https://lists.fd.io/g/vpp-dev/message/11666
Mute This Topic: https://lists.fd.io/mt/28790237/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 Review: https://gerrit.fd.io/r/#/c/15084/:

[Gonsalves, Avinash (Nokia - IN/Bangalore)]

We had done this a while back, I was checking the code if I had missed out 
anything.
I agree this can be a MP/SC. I’ve not tested this, but let me get back with 
some test results.

Thanks,
Avinash

From: Kingwel Xie 
Sent: Tuesday, December 18, 2018 2:47 PM
To: Gonsalves, Avinash (Nokia - IN/Bangalore) ; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:

Hi Avinash,

My question about the MP/MC ring flag that you made a patch to DPDK, any 
comments?

I’d like them to be MP/SC, as we always have only one consumer.

Regards,
Kingwel

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Gonsalves, 
Avinash (Nokia - IN/Bangalore)
Sent: Tuesday, December 18, 2018 3:33 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:


Hi Damjan, Kingwel,

Most of the changes in the dpdk plugin is generic and works for other crypto 
devices as well, so can we have this patch integrated while the design with VPP 
Native support is being discussed?

The DPDK patch has been forwarded separately to the DPDK community.

Please find scaling numbers for a sample IMIX profile:

[cid:image001.jpg@01D496E1.1BA25B20]




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11667): https://lists.fd.io/g/vpp-dev/message/11667
Mute This Topic: https://lists.fd.io/mt/28779969/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] Config NAT plugin for with dynamic translations

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

I think this is issue when handoff queue is congested (multiple workers), this 
was fixed in 18.10

Matus


From: vpp-dev@lists.fd.io  On Behalf Of 
david.leitch@gmail.com
Sent: Tuesday, December 18, 2018 10:36 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Config NAT plugin for with dynamic translations

vpp 18.04 NAT plugin has bug or it does not work ???
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11668): https://lists.fd.io/g/vpp-dev/message/11668
Mute This Topic: https://lists.fd.io/mt/28790237/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] Sanity check re: NAT for same-service mapping

[JB]

Hi Matus,

That is... Interesting. Is the behaviour dependent on the presence of STUN 
packets?

Sincerely,
John

Sent from my phone




On Tue, Dec 18, 2018 at 10:08 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone



On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.



RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787

Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the provider to be strict on their internal allocation of RFC6598 
(CGNAT) address space otherwise they'll have to allocate large networks that 
would be mostly unused, and very wasteful computationally when traversing the 
NAT allocations.



Kind regards,



John



From: Ole Troan

Sent: Monday, December 17, 2018 10:26 PM

To: John Biscevic

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



> This might be best answered by Matus since it regards NAT, but I'll throw it 
> out there for the whole group.

>

> The endpoint-dependent feature of the NAT plugin - Endpoint address AND port 
> dependent I presume from the 6-tuple description of it - allows us to map the 
> same internal source IP and port to the same external IP when targeting a 
> certain past destination IP AND port, correct?

> My concern is more of the situations where services initially create a 
> connection to one endpoint address, and then create another session to 
> another endpoint address, expecting the same source address to match the 
> client.

>

> Client opens a connection to endpoint X using external IP A, which proceeds 
> to instruct client to open a session to endpoint Y, both endpoints share the 
> same backend and expect the client to have IP A but since it's a new session 
> and we're doing dynamic NAT, the client ends up with external IP B, breaking 
> the chain. Many services depend on this.

>

> The idea is that when a new NAT source IP is seen, that we reserve a certain 
> number of internal ports for that IP to the same number of external ports on 
> a single IP, so all

Re: [vpp-dev] Sanity check re: NAT for same-service mapping

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

Session/mapping key is 4-tuple (client address, port, fib index and protocol), 
internal address and port is mapped always to same external address and port no 
matter what is the endpoint 
https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=src/plugins/nat/nat.h;h=3ce83ea26022fac43045fc88bfb37466c78c98dd;hb=HEAD#l58

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 10:53 AM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
That is... Interesting. Is the behaviour dependent on the presence of STUN 
packets?
Sincerely,
John
Sent from my phone



On Tue, Dec 18, 2018 at 10:08 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:
Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone




On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.



RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787

Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the provider to be strict on their internal allocation of RFC6598 
(CGNAT) address space otherwise they'll have to allocate large networks that 
would be mostly unused, and very wasteful computationally when traversing the 
NAT allocations.



Kind regards,



John



From: Ole Troan

Sent: Monday, December 17, 2018 10:26 PM

To: John Biscevic

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



> This might be best answered by Matus since it regards NAT, but I'll throw it 
> out there for the whole group.

>

> The endpoint-dependent feature of the NAT plugin - Endpoint address AND port 
> dependent I presume from the 6-tuple description of it - allows us to map the 
> same internal source IP and port to the same external IP when targeting a 
> certain past destination IP AND port, correct?

> My concern is more of the situations where services initially create a 
> connection to one endpoint addres

[vpp-dev] BRODCOM Iterfaces(BCM95720) after biding with DPDK , Not reflecting in VPP #vpp

[Nixon Raj via Lists.Fd.Io]

VPP Version : v18.07.1
DPDK Version:  DPDK 18.05.0

# vppctl show pci

:01:00.0      14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...
:01:00.1      14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...
:02:00.0      14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...
:02:00.1      14e4:165f   5.0 GT/s x1  igb_uio         Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...
:03:00.0      14e4:165f   5.0 GT/s x1  tg3             Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...
:03:00.1      14e4:165f   5.0 GT/s x1  tg3             Broadcom NetXtreme 
Gigabit Ether PN: BCM95720
                                                                                
           EC: 106679-15
                                                                                
           SN: 0123456789
                                                                                
           MN: 14e4
                                                                                
           RV: 0x 1d 00 00 00 00 00 00 00 ...

# vppctl sh int

Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          
Count
local0                            0     down          0/0/0/0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11672): https://lists.fd.io/g/vpp-dev/message/11672
Mute This Topic: https://lists.fd.io/mt/28790956/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] BRODCOM Iterfaces(BCM95720) after biding with DPDK , Not reflecting in VPP #vpp

[Damjan Marion via Lists.Fd.Io]

We never added support for those cards, simply because we don't have them...

-- 
Damjan

> On 18 Dec 2018, at 11:14, Nixon Raj via Lists.Fd.Io 
>  wrote:
> 
> VPP Version : v18.07.1
> DPDK Version:  DPDK 18.05.0
> 
> 
> # vppctl show pci
> 
> :01:00.0  14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> :01:00.1  14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> :02:00.0  14e4:165f   5.0 GT/s x1  uio_pci_generic Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> :02:00.1  14e4:165f   5.0 GT/s x1  igb_uio Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> :03:00.0  14e4:165f   5.0 GT/s x1  tg3 Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> :03:00.1  14e4:165f   5.0 GT/s x1  tg3 Broadcom NetXtreme 
> Gigabit Ether PN: BCM95720
>   
>  EC: 106679-15
>   
>  SN: 0123456789
>   
>  MN: 14e4
>   
>  RV: 0x 1d 00 00 00 00 00 00 00 ...
> 
> # vppctl sh int
> 
> Name   IdxState  MTU (L3/IP4/IP6/MPLS) Counter  
> Count
> local00 down  0/0/0/0
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11672): https://lists.fd.io/g/vpp-dev/message/11672
> Mute This Topic: https://lists.fd.io/mt/28790956/675642
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480514
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11673): https://lists.fd.io/g/vpp-dev/message/11673
Mute This Topic: https://lists.fd.io/mt/28790956/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
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 handoff discussion

[Kingwel Xie]

Unfortunately no. However we did suffer from the packet drop issue due to queue 
full, when system load is not heavy. In the end we discovered some vectors in 
the queue only have very few buffers in them. And if we increased the queue 
size, drop rate goes down.

We have a dpdk ring based mechanism which will handoff gtpu packets from 
ip-gtpu-bypass to gtpu-input, there are two new nodes created for this purpose: 
handoff-node and handoff-input node. A very preliminary measurement shows these 
two nodes take around < 30 clocks in total when handoff only happens within one 
worker thread. Next, we’ll try to measure the overhead of handoff between 
workers. I’m expecting we’ll have significant performance loss due to cache 
misses. Anyway, the good side is, the code is much easier to understand and 
maintain.


See below for ‘show run’ output:

VirtualFunctionEthernet81/10/7   active  4105410509824  
 0  1.37e1  256.00
VirtualFunctionEthernet81/10/7   active  4105410509824  
 0  7.15e1  256.00
dpdk-input   polling 41054   0  
 0  1.83e20.00
ip4-inputactive  4105410509824  
 0  3.61e1  256.00
ip4-lookup   active  4105410509824  
 0  2.47e1  256.00
ip4-ppf-gtpu-bypass  active  4105410509824  
 0  2.93e1  256.00
ip4-rewrite  active  4105410509824  
 0  2.50e1  256.00
pg-input polling 4105410509824  
 0  7.65e1  256.00
ppf-gtpu4-encap  active  4105410509824  
 0  2.91e1  256.00
ppf-gtpu4-input  active  4105410509824  
 0  2.79e1  256.00
ppf-handoff-inputpolling 4105410509824  
 0  1.39e1  256.00
ppf-handoff  active  4105410509824  
 0  1.17e1  256.00
ppf-pdcp-encap   active  4105410509824  
 0  2.69e1  256.00
ppf-pdcp-encrypt active  4105410509824  
 0  1.69e1  256.00
ppf-sb-path-lb   active  4105410509824  
 0  1.19e1  256.00
ppf-sdap-encap   active  4105410509824  
 0  2.64e1  256.00



From: Damjan Marion 
Sent: Tuesday, December 18, 2018 5:18 PM
To: Kingwel Xie 
Cc: vpp-dev@lists.fd.io
Subject: Re: vPP handoff discussion


Possibly, do you have any numbers to support your statement?

--
Damjan


On 18 Dec 2018, at 10:14, Kingwel Xie 
mailto:kingwel@ericsson.com>> wrote:

Hi Damjan,

My fault that I should have made it clear. What I want to say is that I wonder 
if the existing handoff mechanism needs some improvement. Using a ring seems to 
be simpler, and better from performance perspective. Even more, I think it 
could help with the packet drop issue due to bigger and more flexible ring size.

Sorry I changed the subject, it doesn’t strictly follow the original one any 
more.

Regards,
Kingwel

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via Lists.Fd.Io
Sent: Tuesday, December 18, 2018 3:12 PM
To: Kingwel Xie mailto:kingwel@ericsson.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Review: https://gerrit.fd.io/r/#/c/15084/:


Dear Kingwei,

I don't think VPP handoff is right solution for this problem. It can be solved 
in much simpler way.
We can simply have simple ring by worker tthread where new packets pending 
encryption/decryption are enqueued.
Then we can have input node which runs on all threads and  polls those rings. 
When there is new packet on the ring
that input node simply uses atomic compare and swap to declare that it is 
responsible for enc/dec of specific packet.
when encryption is completed, owning thread enqueues packets to the next node 
in preserved packet order...

Does this make sense?

--
Damjan



On 18 Dec 2018, at 03:22, Kingwel Xie 
mailto:kingwel@ericsson.com>> wrote:

Hi Damjan,

Yes, agree with you.

Here I got a thought about handoff mechanism in vPP. If looking into the DPDK 
crypto scheduler, you will find out that it heavily depends on DPDK rings, for 
buffer delivery among CPU cores and even for the packet reordering. Therefore, 
something comes to my mind, why can’t we use a ring for handoff?

First, as you know, the existing handoff is somewhat l

[vpp-dev] Status of PPPoE Plugin

[Raj]

Hello all,

I am trying out PPPoE with VPP and while seaching for its
configuration I found the following thread
https://lists.fd.io/g/vpp-dev/message/10844 which kind of  suggests
that the currently PPPoE is broken and that the code must be moved to
tapv2.

The problem people get is that packets from CP is getting dropped and I quote:

https://lists.fd.io/g/vpp-dev/message/11199>
Since PPPoE control packet is special, which destination MAC is the
PPPoE client's MAC. Need to submit a patch to identify it and not
perform L3 MAC filter in ethernet-input-inline() function.


Just checking if this patch is available or is there any other way to
get PPPoE working in latest version?

Thanks and Regards,

Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11676): https://lists.fd.io/g/vpp-dev/message/11676
Mute This Topic: https://lists.fd.io/mt/28791570/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] dpdk-input : serious load imbalance

[Damjan Marion via Lists.Fd.Io]

What kind of nic do you have? Can you capture "show hardw" ?

-- 
Damjan

> On 18 Dec 2018, at 04:03, mik...@yeah.net wrote:
> 
> Hi,
>I configured 2 worker thread and 2 dpdk rx-queuein startup.conf . Then I 
> forged 400w packets and send them to a single dpdk interface . It turns out 
> that the second thread received only 24 packets .I test it for several times 
> and the results are almost the same. Why did this happen ?
> 
>Here is some config and "show":
> VPP : 18.07
> startup.conf:
> cpu {
> main-core 1
> corelist-workers 2,3
> }
> 
> dpdk {
>  dev default {
>  num-rx-queues 2
>  num-tx-queues 2
>  }
> }
> 
> packets:
> these pkts share the same src mac  , dst mac  and ipv4 body , only ipv4 src 
> ip and dst ip are different from each other.
> 
> 
> --
> # sh runtime
> Thread 1 vpp_wk_0 (lcore 2)
> Time 69.8, average vectors/node 1.02, last 128 main loops 0.00 per node 0.00
>   vector rates in 5.7911e4, out 5.0225e2, drop 5.7783e4, punt 0.e0
>  Name State Calls  Vectors
> Suspends Clocks   Vectors/Call  
> dpdk-input   polling 104246554 3999630
>0  7.84e2 .04
> ---
> Thread 2 vpp_wk_1 (lcore 3)
> Time 69.8, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
>   vector rates in 5.1557e-1, out 1.7186e-1, drop 5.1557e-1, punt 0.e0
>  Name State Calls  Vectors
> Suspends Clocks   Vectors/Call  
> dpdk-input   polling 13239  24
>0  1.59e80.00
> -
> # show interface rx-placement 
> Thread 1 (vpp_wk_0):
>   node dpdk-input:
> VirtualFunctionEthernet5/0/2 queue 0 (polling)
> VirtualFunctionEthernet5/0/3 queue 0 (polling)
> Thread 2 (vpp_wk_1):
>   node dpdk-input:
> VirtualFunctionEthernet5/0/2 queue 1 (polling)
> VirtualFunctionEthernet5/0/3 queue 1 (polling)
> -
> vpp# show interface 
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
> Counter  Count 
> VirtualFunctionEthernet5/0/2  1  up  9000/0/0/0 rx 
> packets   3999654
>   
>  rx bytes   687940488
>   
>  tx packets 35082
>   
>  tx bytes 9647550
>   
>  rx-miss  346
> VirtualFunctionEthernet5/0/3  2 down 9000/0/0/0 
> local00 down  0/0/0/0   
> 
> 
> Thanks in advance.
> Mikado
> mik...@yeah.net -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11675): https://lists.fd.io/g/vpp-dev/message/11675 
> 
> Mute This Topic: https://lists.fd.io/mt/28791566/675642 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [dmar...@me.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11678): https://lists.fd.io/g/vpp-dev/message/11678
Mute This Topic: https://lists.fd.io/mt/28791566/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] Sanity check re: NAT for same-service mapping

[JB]

Hi Matus,

Brilliant, thanks!

However, then isn't it possible for a client to end up exposing two different 
external IPs to an endpoint if the client opens two separate sessions over two 
different ports?

John

Sent from my phone




On Tue, Dec 18, 2018 at 10:28 AM +, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES@Cisco) via Lists.Fd.Io" 
mailto:matfabia=cisco@lists.fd.io>> wrote:

Session/mapping key is 4-tuple (client address, port, fib index and protocol), 
internal address and port is mapped always to same external address and port no 
matter what is the endpoint 
https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=src/plugins/nat/nat.h;h=3ce83ea26022fac43045fc88bfb37466c78c98dd;hb=HEAD#l58

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 10:53 AM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
That is... Interesting. Is the behaviour dependent on the presence of STUN 
packets?
Sincerely,
John
Sent from my phone



On Tue, Dec 18, 2018 at 10:08 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:
Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone




On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.



RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787

Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the provider to be strict on their internal allocation of RFC6598 
(CGNAT) address space otherwise they'll have to allocate large networks that 
would be mostly unused, and very wasteful computationally when traversing the 
NAT allocations.



Kind regards,



John



From: Ole Troan

Sent: Monday, December 17, 2018 10:26 PM

To: John Biscevic

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



> This might be best answered by Matus since it regards NAT, but I'll throw it 
> out there for the whole group.

Re: [vpp-dev] Sanity check re: NAT for same-service mapping

[Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

When external address used in first session has allocated all available ports 
second session use another external address if it is available (when you have 2 
external addresses nat start using first and when all ports are allocated it 
moves to second one)

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 2:23 PM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
Brilliant, thanks!
However, then isn't it possible for a client to end up exposing two different 
external IPs to an endpoint if the client opens two separate sessions over two 
different ports?
John
Sent from my phone



On Tue, Dec 18, 2018 at 10:28 AM +, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES@Cisco) via Lists.Fd.Io" 
mailto:matfabia=cisco@lists.fd.io>> wrote:
Session/mapping key is 4-tuple (client address, port, fib index and protocol), 
internal address and port is mapped always to same external address and port no 
matter what is the endpoint 
https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=src/plugins/nat/nat.h;h=3ce83ea26022fac43045fc88bfb37466c78c98dd;hb=HEAD#l58

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:53 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
That is... Interesting. Is the behaviour dependent on the presence of STUN 
packets?
Sincerely,
John
Sent from my phone




On Tue, Dec 18, 2018 at 10:08 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:
Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone





On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are reserved for the 
source IP and source port, in any larger deployment, another source IP might 
occupy it before we get a chance to.



RFC4787 Section 4, REQ-2 and Section 5 describe it rather well: 
https://tools.ietf.org/html/rfc4787

Also, RFC6888 does reflect its implementation for CGN, in which Endpoint 
independent mapping is almost necessary, unless deterministic NAT (potentially 
highly wasteful though) is used, as in the case where we use deterministic NAT 
it requires the pr

Re: [vpp-dev] Sanity check re: NAT for same-service mapping

[JB]

Hi Matus,

Thanks, that's how I figured that it works, and was the root of my concern and 
the idea of reserving ports for a client equivalent to max translations per 
user to avoid such scenarios. It's potentially wasteful but a fail-safe against 
such scenarios.

Much appreciated that you've taken your time so far!

John

Sent from my phone




On Tue, Dec 18, 2018 at 1:29 PM +, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

When external address used in first session has allocated all available ports 
second session use another external address if it is available (when you have 2 
external addresses nat start using first and when all ports are allocated it 
moves to second one)

Matus


From: John Biscevic 
Sent: Tuesday, December 18, 2018 2:23 PM
To: Ole Troan ; Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
Brilliant, thanks!
However, then isn't it possible for a client to end up exposing two different 
external IPs to an endpoint if the client opens two separate sessions over two 
different ports?
John
Sent from my phone



On Tue, Dec 18, 2018 at 10:28 AM +, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES@Cisco) via Lists.Fd.Io" 
mailto:matfabia=cisco@lists.fd.io>> wrote:
Session/mapping key is 4-tuple (client address, port, fib index and protocol), 
internal address and port is mapped always to same external address and port no 
matter what is the endpoint 
https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=src/plugins/nat/nat.h;h=3ce83ea26022fac43045fc88bfb37466c78c98dd;hb=HEAD#l58

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:53 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
That is... Interesting. Is the behaviour dependent on the presence of STUN 
packets?
Sincerely,
John
Sent from my phone




On Tue, Dec 18, 2018 at 10:08 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:
Endpoint independent mapping is default behaviour

Matus


From: John Biscevic 
mailto:john.bisce...@bahnhof.net>>
Sent: Tuesday, December 18, 2018 10:03 AM
To: Ole Troan mailto:otr...@employees.org>>; Matus Fabian 
-X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
mailto:matfa...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping

Hi Matus,
There must be some misunderstanding!
We're discussing endpoint INdependent mapping which as far as I know isn't 
currently present in VPP.
The issue being that the current NAT implementations break certain services as 
clients end up with different external IPs in various situations where an 
endpoint service might use a different IP and port but still expect the same 
IP, or where the desired external IP and port can't be reused since another 
session has occupied them because they're not reserved for the client.
Sincerely,
John
Sent from my phone





On Tue, Dec 18, 2018 at 8:57 AM +0100, "Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco)" mailto:matfa...@cisco.com>> wrote:

Hi,



Endpoint-dependent NAT is not default behaviour, when you want to use 
endpoint-dependent NAT you need to adjust startup config 
https://wiki.fd.io/view/VPP/NAT#NAT44



Matus



-Original Message-

From: vpp-dev@lists.fd.io  On Behalf Of JB

Sent: Tuesday, December 18, 2018 12:02 AM

To: Ole Troan

Cc: vpp-dev@lists.fd.io

Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping



Hi Ole,



Absolutely, Endpoint independent mapping is the safest bet, which is why it is 
recommended. It is unfortunate that we cannot rely on services being IP source 
agnostic or that STUN will be used.

Thus, even though Endpoint independent mapping can be considered non-efficient 
in its address and port allocation, we should perhaps consider it being the 
default implementation as the other implementation would be circumstantial and 
would benefit specific NAT deployments rather than require them, or else we run 
the risk of seeing broken services during NAT, especially on larger deployments.



That way, exactly as you say, we could do endpoint dependent address and port 
mapping for the applications we know are safe, but would come second in 
priority.



Interestingly enough, there's a scenario where we run into the danger of being 
unable to enact a proper remapping according to Endpoint independent mapping if 
all we do is track source IP and source port to the same external IP and 
external port from a pool, which is that unless those are res

[vpp-dev] Kubecon EU CFP closes Jan 18

[Edward Warnicke]

For folks in the FD.io community looking to submit talks to the Kubecon EU
CFP:

https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/cfp/

It closes Jan 18.

Ed
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11684): https://lists.fd.io/g/vpp-dev/message/11684
Mute This Topic: https://lists.fd.io/mt/28795578/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] MAP-E/MAP-T Futures?

[Jon Loeliger]

On Mon, Dec 17, 2018 at 5:50 AM Ole Troan  wrote:

> Hi Jon,
>
> > Is it your intention to re-factor the changes in
> > https://gerrit.fd.io/r/14247
> > to remove the FIB DPO and instead use an input feature?
>
> Yes, that was the plan.
> Of course we could keep the DPO code in there, and even make it a
> configuration knob which one to choose.
>

Ole,

I have a patch that adds just the new API calls from 14247, but doesn't
address
any of the direct DPO/input-feature changes yet.  I'm not certain about
those changes, nor how they would interact if both choices are made
available.
I could easily add the 14247 changes that add the lpm pieces, but I'm not
sure how they would tie-in with some of the other changes there.

I will post my patch as-is, and we can go from there.

jdl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11685): https://lists.fd.io/g/vpp-dev/message/11685
Mute This Topic: https://lists.fd.io/mt/28757044/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] dpdk-input : serious load imbalance

[Damjan Marion via Lists.Fd.Io]

What version of VPP do you use.
I'm missing some outputs in "show hardware"...

-- 
Damjan

> On 19 Dec 2018, at 02:19, mik...@yeah.net wrote:
> 
> The "show hardw" is as follow, the statistics may be different from yesterday.
> 
> vpp# show hardware-interfaces 
> Name Idx Link Hardware
> VirtualFunctionEthernet5/0/2 1 up VirtualFunctionEthernet5/0/2
> Ethernet address 72:62:8a:40:43:12
> Cavium ThunderX
> carrier up full duplex speed 1 mtu 9190 
> flags: admin-up pmd maybe-multiseg
> rx queues 2, rx desc 1024, tx queues 2, tx desc 1024
> cpu socket 0
> 
> tx frames ok 268302
> tx bytes ok 74319654
> rx frames ok 400
> rx bytes ok 68800
> extended stats:
> rx good packets 400
> tx good packets 268302
> rx good bytes 68800
> tx good bytes 74319654
> rx q0packets 376
> rx q0bytes 687995872
> rx q1packets 24
> rx q1bytes 4128
> tx q0packets 12
> tx q0bytes 3324
> tx q1packets 268290
> tx q1bytes 74316330
> VirtualFunctionEthernet5/0/3 2 down VirtualFunctionEthernet5/0/3
> Ethernet address 2a:f2:d5:47:67:f1
> Cavium ThunderX
> carrier down 
> flags: pmd maybe-multiseg
> rx queues 2, rx desc 1024, tx queues 2, tx desc 1024
> cpu socket 0
> 
> local0 0 down local0
> local
> 
> mik...@yeah.net 
>  
> From: Damjan Marion 
> Date: 2018-12-18 20:38
> To: mik...@yeah.net 
> CC: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] dpdk-input : serious load imbalance
> 
> What kind of nic do you have? Can you capture "show hardw" ?
> 
> -- 
> Damjan
> 
>> On 18 Dec 2018, at 04:03, mik...@yeah.net  wrote:
>> 
>> Hi,
>>I configured 2 worker thread and 2 dpdk rx-queuein startup.conf . Then I 
>> forged 400w packets and send them to a single dpdk interface . It turns out 
>> that the second thread received only 24 packets .I test it for several times 
>> and the results are almost the same. Why did this happen ?
>> 
>>Here is some config and "show":
>> VPP : 18.07
>> startup.conf:
>> cpu {
>> main-core 1
>> corelist-workers 2,3
>> }
>> 
>> dpdk {
>>  dev default {
>>  num-rx-queues 2
>>  num-tx-queues 2
>>  }
>> }
>> 
>> packets:
>> these pkts share the same src mac  , dst mac  and ipv4 body , only ipv4 src 
>> ip and dst ip are different from each other.
>> 
>> 
>> --
>> # sh runtime
>> Thread 1 vpp_wk_0 (lcore 2)
>> Time 69.8, average vectors/node 1.02, last 128 main loops 0.00 per node 0.00
>>   vector rates in 5.7911e4, out 5.0225e2, drop 5.7783e4, punt 0.e0
>>  Name State Calls  Vectors   
>>  Suspends Clocks   Vectors/Call  
>> dpdk-input   polling 104246554 3999630   
>> 0  7.84e2 .04
>> ---
>> Thread 2 vpp_wk_1 (lcore 3)
>> Time 69.8, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
>>   vector rates in 5.1557e-1, out 1.7186e-1, drop 5.1557e-1, punt 0.e0
>>  Name State Calls  Vectors   
>>  Suspends Clocks   Vectors/Call  
>> dpdk-input   polling 13239  24   
>> 0  1.59e80.00
>> -
>> # show interface rx-placement 
>> Thread 1 (vpp_wk_0):
>>   node dpdk-input:
>> VirtualFunctionEthernet5/0/2 queue 0 (polling)
>> VirtualFunctionEthernet5/0/3 queue 0 (polling)
>> Thread 2 (vpp_wk_1):
>>   node dpdk-input:
>> VirtualFunctionEthernet5/0/2 queue 1 (polling)
>> VirtualFunctionEthernet5/0/3 queue 1 (polling)
>> -
>> vpp# show interface 
>>   Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
>> Counter  Count 
>> VirtualFunctionEthernet5/0/2  1  up  9000/0/0/0 rx 
>> packets   3999654
>>  
>>   rx bytes   687940488
>>  
>>   tx packets 35082
>>  
>>   tx bytes 9647550
>>  
>>   rx-miss  346
>> VirtualFunctionEthernet5/0/3  2 down 9000/0/0/0 
>> local00 down  0/0/0/0   
>> 
>> 
>> Thanks in advance.
>> Mikado
>> mik...@yeah.net -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Onl

Re: [vpp-dev] Worker Thread Dead Lock on NAT44 IPFIX

[david . leitch . vpp]

*hi*
 
*Every time I enable ipfix for NAT, the main thread (vpp_main) is going too 
slowly, which is very hard to enter any command and also drop rate increase 
that all traffic dropped.*
*but I got worker thread deadlock once after some hours.
* *Is it a normal behavior that Every time I enable ipfix for NAT, the main 
thread (vpp_main) is going too slowly ? *
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11687): https://lists.fd.io/g/vpp-dev/message/11687
Mute This Topic: https://lists.fd.io/mt/28792277/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] dpdk-input : serious load imbalance

[Damjan Marion via Lists.Fd.Io]

Can you try to capture "show hardw" with 18.10 ?

Looks like ThunderX is not acting as PCI device so part of the output is 
suppressed in 18.07 and we changed that behaviour in 18.10.

I'm looking for someething like:

rss avail: ipv4 ipv4-tcp ipv4-udp ipv6 ipv6-tcp ipv6-udp ipv6-tcp-ex
   ipv6-udp-ex ipv6-ex ipv6-tcp-ex ipv6-udp-ex
rss active:none


-- 
Damjan

> On 19 Dec 2018, at 08:26, mik...@yeah.net wrote:
> 
> vpp v18.07.1-10~gc548f5d-dirty 
> 
> mik...@yeah.net 
>  
> From: Damjan Marion 
> Date: 2018-12-19 15:21
> To: mik...@yeah.net 
> CC: vpp-dev 
> Subject: Re: [vpp-dev] dpdk-input : serious load imbalance
> 
> What version of VPP do you use.
> I'm missing some outputs in "show hardware"...
> 
> -- 
> Damjan
> 
>> On 19 Dec 2018, at 02:19, mik...@yeah.net  wrote:
>> 
>> The "show hardw" is as follow, the statistics may be different from 
>> yesterday.
>> 
>> vpp# show hardware-interfaces 
>> Name Idx Link Hardware
>> VirtualFunctionEthernet5/0/2 1 up VirtualFunctionEthernet5/0/2
>> Ethernet address 72:62:8a:40:43:12
>> Cavium ThunderX
>> carrier up full duplex speed 1 mtu 9190 
>> flags: admin-up pmd maybe-multiseg
>> rx queues 2, rx desc 1024, tx queues 2, tx desc 1024
>> cpu socket 0
>> 
>> tx frames ok 268302
>> tx bytes ok 74319654
>> rx frames ok 400
>> rx bytes ok 68800
>> extended stats:
>> rx good packets 400
>> tx good packets 268302
>> rx good bytes 68800
>> tx good bytes 74319654
>> rx q0packets 376
>> rx q0bytes 687995872
>> rx q1packets 24
>> rx q1bytes 4128
>> tx q0packets 12
>> tx q0bytes 3324
>> tx q1packets 268290
>> tx q1bytes 74316330
>> VirtualFunctionEthernet5/0/3 2 down VirtualFunctionEthernet5/0/3
>> Ethernet address 2a:f2:d5:47:67:f1
>> Cavium ThunderX
>> carrier down 
>> flags: pmd maybe-multiseg
>> rx queues 2, rx desc 1024, tx queues 2, tx desc 1024
>> cpu socket 0
>> 
>> local0 0 down local0
>> local
>> 
>> mik...@yeah.net 
>>  
>> From: Damjan Marion 
>> Date: 2018-12-18 20:38
>> To: mik...@yeah.net 
>> CC: vpp-dev@lists.fd.io 
>> Subject: Re: [vpp-dev] dpdk-input : serious load imbalance
>> 
>> What kind of nic do you have? Can you capture "show hardw" ?
>> 
>> -- 
>> Damjan
>> 
>>> On 18 Dec 2018, at 04:03, mik...@yeah.net  wrote:
>>> 
>>> Hi,
>>>I configured 2 worker thread and 2 dpdk rx-queuein startup.conf . Then I 
>>> forged 400w packets and send them to a single dpdk interface . It turns out 
>>> that the second thread received only 24 packets .I test it for several 
>>> times 
>>> and the results are almost the same. Why did this happen ?
>>> 
>>>Here is some config and "show":
>>> VPP : 18.07
>>> startup.conf:
>>> cpu {
>>> main-core 1
>>> corelist-workers 2,3
>>> }
>>> 
>>> dpdk {
>>>  dev default {
>>>  num-rx-queues 2
>>>  num-tx-queues 2
>>>  }
>>> }
>>> 
>>> packets:
>>> these pkts share the same src mac  , dst mac  and ipv4 body , only ipv4 src 
>>> ip and dst ip are different from each other.
>>> 
>>> 
>>> --
>>> # sh runtime
>>> Thread 1 vpp_wk_0 (lcore 2)
>>> Time 69.8, average vectors/node 1.02, last 128 main loops 0.00 per node 0.00
>>>   vector rates in 5.7911e4, out 5.0225e2, drop 5.7783e4, punt 0.e0
>>>  Name State Calls  Vectors  
>>>   Suspends Clocks   Vectors/Call  
>>> dpdk-input   polling 104246554 3999630  
>>>  0  7.84e2 .04
>>> ---
>>> Thread 2 vpp_wk_1 (lcore 3)
>>> Time 69.8, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
>>>   vector rates in 5.1557e-1, out 1.7186e-1, drop 5.1557e-1, punt 0.e0
>>>  Name State Calls  Vectors  
>>>   Suspends Clocks   Vectors/Call  
>>> dpdk-input   polling 13239  24  
>>>  0  1.59e80.00
>>> -
>>> # show interface rx-placement 
>>> Thread 1 (vpp_wk_0):
>>>   node dpdk-input:
>>> VirtualFunctionEthernet5/0/2 queue 0 (polling)
>>> VirtualFunctionEthernet5/0/3 queue 0 (polling)
>>> Thread 2 (vpp_wk_1):
>>>   node dpdk-input:
>>> VirtualFunctionEthernet5/0/2 queue 1 (polling)
>>> VirtualFunctionEthernet5/0/3 queue 1 (polling)
>>> -
>>> vpp# show interface 
>>>   Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
>>> Counter  Count 
>>> VirtualFunctionEthernet5/0/2  1  up  900