答复: [vpp-dev] Assertion fails in external echo server/client

[yexin (F)]

Hi Florin,

The problem observed is in v18.07, not the rc, and the line is at 1126 (session 
= pool_elt_at_index ()), sorry for wrong version last time.

-
YeXin

发件人: Florin Coras [mailto:fcoras.li...@gmail.com]
发送时间: 2018年8月6日 23:35
收件人: yexin (F) 
抄送: vpp-dev@lists.fd.io; wangyalei (A) 
主题: Re: [vpp-dev] Assertion fails in external echo server/client

Hi YeXin,

First of all, do you see this with 18.07 or master? Secondly, I’ve checked out 
origin/stable/1804 and at line 1126 there’s no attempt to access a pool. Are 
you testing with rc0 or custom code?

Thanks,
Florin


On Aug 5, 2018, at 11:29 PM, yexin (F) 
mailto:yexi...@huawei.com>> wrote:

The version tested is v18.04.

发件人: yexin (F)
发送时间: 2018年8月6日 14:22
收件人: 'vpp-dev@lists.fd.io' 
mailto:vpp-dev@lists.fd.io>>
抄送: wangyalei (A) 
mailto:william.wangya...@huawei.com>>
主题: Assertion fails in external echo server/client

Hi vpp-dev,

I get the “assertion failure” when test external echo server/client by doing 
below:

1.  Build the external test echo apps
2.  Start vpp1 and attach the server application, `./tcp_echo uri 
tcp://192.168.122.67/1 use-svm-api`
3.  Start vpp2 and connect to tcp_echo server from vpp prompt, `vpp# test 
echo clients uri tcp://192.168.122.67/1`

Then the server crashed due to assertion failure. The error message looks like:

‘/vpp/src/tests/vnet/session/tcp_echo.c:1126(server_handle_fifo_event_rx) 
assertion `! pool_is_free (em->sessions, _e)` fails’

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

View/Reply Online (#10039): https://lists.fd.io/g/vpp-dev/message/10039
Mute This Topic: https://lists.fd.io/mt/24206621/675152
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[fcoras.li...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10056): https://lists.fd.io/g/vpp-dev/message/10056
Mute This Topic: https://lists.fd.io/mt/24217935/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] tx-drops with vhost-user interface

[Yichen Wang via Lists.Fd.Io]

Hi, Vijay,

Sorry to ask dumb question, can you make sure the interface in your VM (either 
Linux Kernel or DPDK) is “UP”?

Regards,
Yichen

From:  on behalf of "steven luong via Lists.Fd.Io" 

Reply-To: "Steven Luong (sluong)" 
Date: Monday, August 6, 2018 at 12:10 PM
To: "Chandra Mohan, Vijay Mohan" , "vpp-dev@lists.fd.io" 

Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] tx-drops with vhost-user interface

Vijay,

From the show output, I can’t really tell what your problem is. If you could 
provide additional information about your environment, I could try setting it 
up and see what’s wrong. Things I need from you are exact VPP version, VPP 
configuration, qemu startup command line or the XML startup file if you use 
virsh, and the version of the VM distro.

Steven

From:  on behalf of "Chandra Mohan, Vijay Mohan" 

Date: Monday, August 6, 2018 at 10:31 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] tx-drops with vhost-user interface

Hi,

I am trying to pass traffic with vhost-user interface and seeing tx-drops on 
virtual interface. Here is the setup: created a bridge domain with a physical 
interface and a vhost-user interface. Physical interface GigabitEthernet5/0/0 
is connected to traffic generator. As shown below, observing drops on  
VirtualEthernet0/0/0 .

Following is the config and vhost-user commands o/p:

DBGvpp# show bridge-domain 1 detail
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd  UU-Flood  Flooding  
ARP-Term  BVI-Intf
1   1  0 offonononon   off  
 N/A

   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite
 GigabitEthernet5/0/03 10-  * none
 GigabitEthernet5/0/14 10-  * none
 VirtualEthernet0/0/05 10-  * none

Virtual interface is operationally up. Connected to virtual interface server in 
VM.

DBGvpp# show hardware-interfaces VirtualEthernet0/0/0
  NameIdx   Link  Hardware
VirtualEthernet0/0/0   5 up   VirtualEthernet0/0/0
  Ethernet address 02:fe:98:19:c2:6b

DBGvpp# show interface VirtualEthernet0/0/0

  Name   Idx   State  Counter  Count

VirtualEthernet0/0/0  5 up   tx packets 
1

 tx bytes   
   60

 drops  
1





DBGvpp# show errors

   CountNode  Reason

 3l2-output   L2 output packets

 2l2-learnL2 learn packets

 2l2-learnL2 learn misses

 2l2-inputL2 input packets

 3l2-floodL2 flood packets

 1 VirtualEthernet0/0/0-txtx packet drops (no available 
descriptors)


DBGvpp# show vhost-user VirtualEthernet0/0/0
Virtio vhost-user interfaces
Global:
  coalesce frames 32 time 1e-3
  number of rx virtqueues in interrupt mode: 0
Interface: VirtualEthernet0/0/0 (ifindex 5)
virtio_net_hdr_sz 12
features mask (0x):
 features (0x150208000):
   VIRTIO_NET_F_MRG_RXBUF (15)
   VIRTIO_NET_F_GUEST_ANNOUNCE (21)
   VIRTIO_F_INDIRECT_DESC (28)
   VHOST_USER_F_PROTOCOL_FEATURES (30)
   VIRTIO_F_VERSION_1 (32)
  protocol features (0x3)
   VHOST_USER_PROTOCOL_F_MQ (0)
   VHOST_USER_PROTOCOL_F_LOG_SHMFD (1)

socket filename /socket/vnet-0 type client errno "Success"

rx placement:
   thread 0 on vring 1, polling
tx placement: lock-free
   thread 0 on vring 0

Memory regions (total 3)
region fdguest_phys_addrmemory_sizeuserspace_addr 
mmap_offsetmmap_addr
== = == == == 
== ==
  0 500x0001 0x0001c000 0x7fe39360 
0xc000 0x7fc0e4a0
  1 510x 0x000a 0x7fe2d360 
0x 0x7fc02480
  2 520x000c 0xbff4 0x7fe2d36c 
0x000c 0x7fbf648c

Virtqueue 0 (TX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 53 callfd 54 errfd -1

Virtqueue 1 (RX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 46 callfd 55 errfd -1

Tried dumping descriptors from Rx queue and didn’t find any entries. It’s all 
zeros.

Any idea what is going on here ?

Thanks,
Vijay

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

View/Reply Online (#10055): https://lists.fd.io/g/vpp-dev/message/10055
Mute This Topic: https://lists.fd.io/mt/24211191/21656
Gr

Re: [vpp-dev] tx-drops with vhost-user interface

[steven luong via Lists.Fd.Io]

Vijay,

From the show output, I can’t really tell what your problem is. If you could 
provide additional information about your environment, I could try setting it 
up and see what’s wrong. Things I need from you are exact VPP version, VPP 
configuration, qemu startup command line or the XML startup file if you use 
virsh, and the version of the VM distro.

Steven

From:  on behalf of "Chandra Mohan, Vijay Mohan" 

Date: Monday, August 6, 2018 at 10:31 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] tx-drops with vhost-user interface

Hi,

I am trying to pass traffic with vhost-user interface and seeing tx-drops on 
virtual interface. Here is the setup: created a bridge domain with a physical 
interface and a vhost-user interface. Physical interface GigabitEthernet5/0/0 
is connected to traffic generator. As shown below, observing drops on  
VirtualEthernet0/0/0 .

Following is the config and vhost-user commands o/p:

DBGvpp# show bridge-domain 1 detail
  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd  UU-Flood  Flooding  
ARP-Term  BVI-Intf
1   1  0 offonononon   off  
 N/A

   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite
 GigabitEthernet5/0/03 10-  * none
 GigabitEthernet5/0/14 10-  * none
 VirtualEthernet0/0/05 10-  * none

Virtual interface is operationally up. Connected to virtual interface server in 
VM.

DBGvpp# show hardware-interfaces VirtualEthernet0/0/0
  NameIdx   Link  Hardware
VirtualEthernet0/0/0   5 up   VirtualEthernet0/0/0
  Ethernet address 02:fe:98:19:c2:6b

DBGvpp# show interface VirtualEthernet0/0/0

  Name   Idx   State  Counter  Count

VirtualEthernet0/0/0  5 up   tx packets 
1

 tx bytes   
   60

 drops  
1





DBGvpp# show errors

   CountNode  Reason

 3l2-output   L2 output packets

 2l2-learnL2 learn packets

 2l2-learnL2 learn misses

 2l2-inputL2 input packets

 3l2-floodL2 flood packets

 1 VirtualEthernet0/0/0-txtx packet drops (no available 
descriptors)


DBGvpp# show vhost-user VirtualEthernet0/0/0
Virtio vhost-user interfaces
Global:
  coalesce frames 32 time 1e-3
  number of rx virtqueues in interrupt mode: 0
Interface: VirtualEthernet0/0/0 (ifindex 5)
virtio_net_hdr_sz 12
features mask (0x):
 features (0x150208000):
   VIRTIO_NET_F_MRG_RXBUF (15)
   VIRTIO_NET_F_GUEST_ANNOUNCE (21)
   VIRTIO_F_INDIRECT_DESC (28)
   VHOST_USER_F_PROTOCOL_FEATURES (30)
   VIRTIO_F_VERSION_1 (32)
  protocol features (0x3)
   VHOST_USER_PROTOCOL_F_MQ (0)
   VHOST_USER_PROTOCOL_F_LOG_SHMFD (1)

socket filename /socket/vnet-0 type client errno "Success"

rx placement:
   thread 0 on vring 1, polling
tx placement: lock-free
   thread 0 on vring 0

Memory regions (total 3)
region fdguest_phys_addrmemory_sizeuserspace_addr 
mmap_offsetmmap_addr
== = == == == 
== ==
  0 500x0001 0x0001c000 0x7fe39360 
0xc000 0x7fc0e4a0
  1 510x 0x000a 0x7fe2d360 
0x 0x7fc02480
  2 520x000c 0xbff4 0x7fe2d36c 
0x000c 0x7fbf648c

Virtqueue 0 (TX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 53 callfd 54 errfd -1

Virtqueue 1 (RX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 46 callfd 55 errfd -1

Tried dumping descriptors from Rx queue and didn’t find any entries. It’s all 
zeros.

Any idea what is going on here ?

Thanks,
Vijay

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

View/Reply Online (#10054): https://lists.fd.io/g/vpp-dev/message/10054
Mute This Topic: https://lists.fd.io/mt/24211191/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] [FD.io Helpdesk #59254] AutoReply: git.fd.io expired certificate error

[Dave Barach via RT]

Would it be possible to bump the priority of this ticket?

Thanks... Dave

From: Luke, Chris 
Sent: Monday, August 6, 2018 12:30 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: RE: git.fd.io expired certificate error

FWIW, this is why Coverity scans have stopped, too.

Chris (back from PTO)

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, August 6, 2018 11:21
To: helpd...@fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] git.fd.io expired certificate error

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave


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

View/Reply Online (#10053): https://lists.fd.io/g/vpp-dev/message/10053
Mute This Topic: https://lists.fd.io/mt/24211351/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] tx-drops with vhost-user interface

[Chandra Mohan, Vijay Mohan]

Hi,

I am trying to pass traffic with vhost-user interface and seeing tx-drops on 
virtual interface. Here is the setup: created a bridge domain with a physical 
interface and a vhost-user interface. Physical interface GigabitEthernet5/0/0 
is connected to traffic generator. As shown below, observing drops on  
VirtualEthernet0/0/0 .

Following is the config and vhost-user commands o/p:


DBGvpp# show bridge-domain 1 detail

  BD-ID   Index   BSN  Age(min)  Learning  U-Forwrd  UU-Flood  Flooding  
ARP-Term  BVI-Intf

1   1  0 offonononon   off  
 N/A



   Interface   If-idx ISN  SHG  BVI  TxFlood
VLAN-Tag-Rewrite

 GigabitEthernet5/0/03 10-  * none

 GigabitEthernet5/0/14 10-  * none

 VirtualEthernet0/0/05 10-  * none


Virtual interface is operationally up. Connected to virtual interface server in 
VM.


DBGvpp# show hardware-interfaces VirtualEthernet0/0/0

  NameIdx   Link  Hardware

VirtualEthernet0/0/0   5 up   VirtualEthernet0/0/0

  Ethernet address 02:fe:98:19:c2:6b

DBGvpp# show interface VirtualEthernet0/0/0

  Name   Idx   State  Counter  Count

VirtualEthernet0/0/0  5 up   tx packets 
1

 tx bytes   
   60

 drops  
1





DBGvpp# show errors

   CountNode  Reason

 3l2-output   L2 output packets

 2l2-learnL2 learn packets

 2l2-learnL2 learn misses

 2l2-inputL2 input packets

 3l2-floodL2 flood packets

 1 VirtualEthernet0/0/0-txtx packet drops (no available 
descriptors)


DBGvpp# show vhost-user VirtualEthernet0/0/0
Virtio vhost-user interfaces
Global:
  coalesce frames 32 time 1e-3
  number of rx virtqueues in interrupt mode: 0
Interface: VirtualEthernet0/0/0 (ifindex 5)
virtio_net_hdr_sz 12
features mask (0x):
 features (0x150208000):
   VIRTIO_NET_F_MRG_RXBUF (15)
   VIRTIO_NET_F_GUEST_ANNOUNCE (21)
   VIRTIO_F_INDIRECT_DESC (28)
   VHOST_USER_F_PROTOCOL_FEATURES (30)
   VIRTIO_F_VERSION_1 (32)
  protocol features (0x3)
   VHOST_USER_PROTOCOL_F_MQ (0)
   VHOST_USER_PROTOCOL_F_LOG_SHMFD (1)

socket filename /socket/vnet-0 type client errno "Success"

rx placement:
   thread 0 on vring 1, polling
tx placement: lock-free
   thread 0 on vring 0

Memory regions (total 3)
region fdguest_phys_addrmemory_sizeuserspace_addr 
mmap_offsetmmap_addr
== = == == == 
== ==
  0 500x0001 0x0001c000 0x7fe39360 
0xc000 0x7fc0e4a0
  1 510x 0x000a 0x7fe2d360 
0x 0x7fc02480
  2 520x000c 0xbff4 0x7fe2d36c 
0x000c 0x7fbf648c

Virtqueue 0 (TX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 53 callfd 54 errfd -1

Virtqueue 1 (RX)
  qsz 256 last_avail_idx 0 last_used_idx 0
  avail.flags 0 avail.idx 0 used.flags 1 used.idx 0
  kickfd 46 callfd 55 errfd -1

Tried dumping descriptors from Rx queue and didn’t find any entries. It’s all 
zeros.

Any idea what is going on here ?

Thanks,
Vijay

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

View/Reply Online (#10052): https://lists.fd.io/g/vpp-dev/message/10052
Mute This Topic: https://lists.fd.io/mt/24211191/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] git.fd.io expired certificate error

[Chris Luke]

FWIW, this is why Coverity scans have stopped, too.

Chris (back from PTO)

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Monday, August 6, 2018 11:21
To: helpd...@fd.io
Cc: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] git.fd.io expired certificate error

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave

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

View/Reply Online (#10051): https://lists.fd.io/g/vpp-dev/message/10051
Mute This Topic: https://lists.fd.io/mt/24210014/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] Assertion fails in external echo server/client

[Florin Coras]

Hi YeXin, 

First of all, do you see this with 18.07 or master? Secondly, I’ve checked out 
origin/stable/1804 and at line 1126 there’s no attempt to access a pool. Are 
you testing with rc0 or custom code?

Thanks, 
Florin

> On Aug 5, 2018, at 11:29 PM, yexin (F)  wrote:
> 
> The version tested is v18.04.
>  
> 发件人: yexin (F) 
> 发送时间: 2018年8月6日 14:22
> 收件人: 'vpp-dev@lists.fd.io '  >
> 抄送: wangyalei (A)  >
> 主题: Assertion fails in external echo server/client
>  
> Hi vpp-dev,
>  
> I get the “assertion failure” when test external echo server/client by doing 
> below:
>  
> 1.  Build the external test echo apps
> 2.  Start vpp1 and attach the server application, `./tcp_echo uri 
> tcp://192.168.122.67/1  use-svm-api`
> 3.  Start vpp2 and connect to tcp_echo server from vpp prompt, `vpp# test 
> echo clients uri tcp://192.168.122.67/1` 
>  
> Then the server crashed due to assertion failure. The error message looks 
> like:
>  
> ‘/vpp/src/tests/vnet/session/tcp_echo.c:1126(server_handle_fifo_event_rx) 
> assertion `! pool_is_free (em->sessions, _e)` fails’
>  
> --
> YeXin
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10039): https://lists.fd.io/g/vpp-dev/message/10039 
> 
> Mute This Topic: https://lists.fd.io/mt/24206621/675152 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [fcoras.li...@gmail.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10050): https://lists.fd.io/g/vpp-dev/message/10050
Mute This Topic: https://lists.fd.io/mt/24206621/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] git.fd.io expired certificate error

[Dave Barach via Lists.Fd.Io]

Please fix AYEC:

Chrome is complaining: "This server could not prove that it is git.fd.io; its 
security certificate expired 3 days ago. This may be caused by a 
misconfiguration or an attacker intercepting your connection. Your computer's 
clock is currently set to Monday, August 6, 2018. Does that look right? If not, 
you should correct your system's clock and then refresh this page."

The cert appears to have expired:

Common Name (CN) git.fd.io
Organization (O) 
Organizational Unit (OU)   
Common Name (CN) Let's Encrypt Authority X3
Organization (O) Let's Encrypt
Organizational Unit (OU)   
Issued On  Saturday, May 5, 2018 at 1:35:20 PM
Expires On Friday, August 3, 2018 at 1:35:20 PM
SHA-256 Fingerprint   05 99 81 C2 61 86 D9 5B C2 83 8A B9 FC 7E 51 9B
0D 2A 1C 57 5B 91 C0 9A AB 97 7F EC 84 23 A2 03
SHA-1 Fingerprint 16 7A E3 74 90 DE DE A5 64 26 8B FC 6F CC 0C A6
AE 60 45 D9

Thanks... Dave

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

View/Reply Online (#10049): https://lists.fd.io/g/vpp-dev/message/10049
Mute This Topic: https://lists.fd.io/mt/24210014/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] Fw: VPP on AWS

[Jerome Tollet via Lists.Fd.Io]

Hi Sandeep,
Yes, you’ll get optimal performance with it.
Jerome


Envoyé de mon iPhone

Le 6 août 2018 à 10:40, Sandeep Bajaj 
mailto:sandeep_ba...@yahoo.com>> a écrit :

Thanks Jerome...I ended up doing that and got it to work with igb_uioWill I 
get the ena performance with this driver ? VPP does seem to have support for 
ena...How can I use ena directly ?

I tried the following :

insmod lib/modules/4.4.0-1061-aws/kernel/drivers/net/ethernet/amazon/ena/ena.ko

insmod: ERROR: could not insert module 
lib/modules/4.4.0-1061-aws/kernel/drivers/net/ethernet/amazon/ena/ena.ko: File 
exists

./usertools/dpdk-devbind.py --status

Network devices using DPDK-compatible driver



:00:06.0 'Device ec20' drv=igb_uio unused=ena


Thanks for all ur help!
Cheers
Sandeep



On Monday, August 6, 2018, 4:32:51 AM PDT, Jerome Tollet via Lists.Fd.Io 
mailto:jtollet=cisco@lists.fd.io>> wrote:



Hi Sandeep,

You can download latest dpdk and compile the missing driver from there.

Jerome



De : mailto:vpp-dev@lists.fd.io>> au nom de "Sandeep Bajaj 
via Lists.Fd.Io" 
mailto:sandeep_bajaj=yahoo@lists.fd.io>>
Répondre à : "sandeep_ba...@yahoo.com" 
mailto:sandeep_ba...@yahoo.com>>
Date : lundi 6 août 2018 à 03:34
À : "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Cc : "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] Fw: VPP on AWS







Hi



I am trying to spin up VPP on AWS(c5.large with ENA adapter), but  I seeing 
this error (missing VFIO/UIO driver). I have installed VPP 18.04 stable on 
ubuntu xenial



vpp.service - vector packet processing engine

   Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: 
enabled)

   Active: active (running) since Sun 2018-08-05 06:39:34 UTC; 5s ago

  Process: 32690 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)

  Process: 32699 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
status=1/FAILURE)

  Process: 32696 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)

 Main PID: 32702 (vpp_main)

Tasks: 4

   Memory: 31.5M

  CPU: 2.775s

   CGroup: /system.slice/vpp.service

   └─32702 /usr/bin/vpp -c /etc/vpp/startup.conf



Aug 05 06:39:34  vpp[32702]: /usr/bin/vpp[32702]: dpdk_config:1275: EAL init 
args: -c 1 -n 4 --huge-dir /run/vpp/hugepages --file-prefix vpp --master-lcore 
0 --socket-mem 2048

Aug 05 06:39:34  /usr/bin/vpp[32702]: vlib_pci_bind_to_uio: Skipping PCI device 
:00:06.0: missing kernel VFIO or UIO driver

Aug 05 06:39:34  /usr/bin/vpp[32702]: dpdk_config:1275: EAL init args: -c 1 -n 
4 --huge-dir /run/vpp/hugepages --file-prefix vpp --master-lcore 0 --socket-mem 
2048

Aug 05 06:39:34 vpp[32702]: EAL: No free hugepages reported in 
hugepages-1048576kB

Aug 05 06:39:35  vpp[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vpp[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: dpdk_ipsec_process:1018: not enough DPDK crypto 
resources, default to OpenSSL

Aug 05 06:39:35  vnet[32702]: dpdk_lib_init:230: DPDK drivers found no ports...





When I try to do modprobe for vfio, I get this FATAL error :

modprobe vfio-pci

modprobe: FATAL: Module vfio-pci not found in directory 
/lib/modules/4.4.0-1061-aws



Any ideas on how to get the missing driver, so that I can have interfaces 
controlled by VPP ?



thanks

Sandeep

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

View/Reply Online (#10047): https://lists.fd.io/g/vpp-dev/message/10047
Mute This Topic: https://lists.fd.io/mt/24205315/882711
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
[sandeep_ba...@yahoo.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10048): https://lists.fd.io/g/vpp-dev/message/10048
Mute This Topic: https://lists.fd.io/mt/24205315/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] Fw: VPP on AWS

[Jerome Tollet via Lists.Fd.Io]

Hi Sandeep,
You can download latest dpdk and compile the missing driver from there.
Jerome

De :  au nom de "Sandeep Bajaj via Lists.Fd.Io" 

Répondre à : "sandeep_ba...@yahoo.com" 
Date : lundi 6 août 2018 à 03:34
À : "vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Fw: VPP on AWS



Hi

I am trying to spin up VPP on AWS(c5.large with ENA adapter), but  I seeing 
this error (missing VFIO/UIO driver). I have installed VPP 18.04 stable on 
ubuntu xenial

vpp.service - vector packet processing engine

   Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: 
enabled)

   Active: active (running) since Sun 2018-08-05 06:39:34 UTC; 5s ago

  Process: 32690 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)

  Process: 32699 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
status=1/FAILURE)

  Process: 32696 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)

 Main PID: 32702 (vpp_main)

Tasks: 4

   Memory: 31.5M

  CPU: 2.775s

   CGroup: /system.slice/vpp.service

   └─32702 /usr/bin/vpp -c /etc/vpp/startup.conf



Aug 05 06:39:34  vpp[32702]: /usr/bin/vpp[32702]: dpdk_config:1275: EAL init 
args: -c 1 -n 4 --huge-dir /run/vpp/hugepages --file-prefix vpp --master-lcore 
0 --socket-mem 2048

Aug 05 06:39:34  /usr/bin/vpp[32702]: vlib_pci_bind_to_uio: Skipping PCI device 
:00:06.0: missing kernel VFIO or UIO driver

Aug 05 06:39:34  /usr/bin/vpp[32702]: dpdk_config:1275: EAL init args: -c 1 -n 
4 --huge-dir /run/vpp/hugepages --file-prefix vpp --master-lcore 0 --socket-mem 
2048

Aug 05 06:39:34 vpp[32702]: EAL: No free hugepages reported in 
hugepages-1048576kB

Aug 05 06:39:35  vpp[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vpp[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: EAL:   Invalid NUMA socket, default to 0

Aug 05 06:39:35  vnet[32702]: dpdk_ipsec_process:1018: not enough DPDK crypto 
resources, default to OpenSSL

Aug 05 06:39:35  vnet[32702]: dpdk_lib_init:230: DPDK drivers found no ports...


When I try to do modprobe for vfio, I get this FATAL error :

modprobe vfio-pci

modprobe: FATAL: Module vfio-pci not found in directory 
/lib/modules/4.4.0-1061-aws

Any ideas on how to get the missing driver, so that I can have interfaces 
controlled by VPP ?

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

View/Reply Online (#10047): https://lists.fd.io/g/vpp-dev/message/10047
Mute This Topic: https://lists.fd.io/mt/24205315/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] [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP artifacts

[pmi...@cisco.com via RT]

Hello Vanessa,

For CSIT it is not about release or not. We would need to increase cadence on 
our weekly jobs to daily. Currently CSIT jobs are all failing as VPP has more 
than 10-15 artifacts in week.
Our defined stable versions of VPP (updated once a week) are not in repo 
anymore or are obsoleting faster than we are updating. This is impacting 
everything.

Right now we are *blocked* and we need to work new solution do adopt.

One of the option is that we will have to start building VPP from scratch for 
every job as we cannot use artifacts anymore. This will cause huge overhead on 
infrastructure and execution times will extend as nexus acted as optimization 
for us.
Right now Nexus is not an option for us anymore. This also means that Nexus 
artifacts will not be tested by CSIT.

Peter Mikus
Engineer – Software
Cisco Systems Limited

-Original Message-
From: Vanessa Valderrama via RT [mailto:fdio-helpd...@rt.linuxfoundation.org] 
Sent: Tuesday, July 31, 2018 8:16 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; infra-steer...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP artifacts

Peter,

We need to make a decision on the number of artifacts to keep. I'd like to 
propose the following

previous release repos - 10 packages per subproject master - 10 to 15 packages 
per subproject

Thank you,
Vanessa

On Tue Jun 05 00:51:02 2018, pmi...@cisco.com wrote:
> Hello Vanessa,
> 
> Thank you for an explanation. Indeed this will impact certain things 
> that are planned like "automatic bisecting" (downloading and testing 
> range of artifacts). Let me analyze current situation with CSIT team 
> and get back to you.
> 
> Peter Mikus
> Engineer – Software
> Cisco Systems Limited
> 
> 
> -Original Message-
>  From: Vanessa Valderrama via RT [mailto:fdio- 
> helpd...@rt.linuxfoundation.org]
> Sent: Monday, June 04, 2018 9:47 PM
> To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; infra-steer...@lists.fd.io; vpp- 
> d...@lists.fd.io
> Subject: [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP 
> artifacts
> 
> Peter,
> 
> The fd.io.master.centos7 repo had to be cleaned up significantly to 
> eliminate Jenkins build timeout errors.  This was discussed in the 
> TSC. Going forward we'll only be keeping an average of 10 of the 
> current release candidate artifacts in the repository.  Please let me 
> know if this retention policy causes an issue for you.
> 
> We do need to clean up the other repositories as well.  Please let me 
> know if you'd like to discuss retention policies.  I'll hold off on 
> cleaning up other repositories for now.
> 
> Thank you,
> Vanessa
> 
> On Wed May 30 10:20:21 2018, pmi...@cisco.com wrote:
> > Hello,
> >
> > I have recently spotted that CentOS repo got reduced and old 
> > binaries are missing [1].
> >
> > Is this expected?
> > Will the similar be done for Ubuntu repos?
> >
> > Was this announced somewhere?
> >
> > Thank you.
> >
> > [1]
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/io/fd/
> > vp
> > p/vpp/
> >
> > Peter Mikus
> > Engineer - Software
> > Cisco Systems Limited
> > [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
> > Think before you print.
> >  This email may contain confidential and privileged material for the  
> > sole use of the intended recipient. Any review, use, distribution or  
> > disclosure by others is strictly prohibited. If you are not the  
> > intended recipient (or authorized to receive for the recipient),  
> > please contact the sender by reply email and delete all copies of 
> > this message.
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 




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

View/Reply Online (#10046): https://lists.fd.io/g/vpp-dev/message/10046
Mute This Topic: https://lists.fd.io/mt/21275985/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] IP reassembly doesn't work in VPP 18.07

[Ole Troan]

Hi there,

> 
> Thanks, Ole, your patch works! May consider how to implement an optimized 
> one. :-) 

Yes, please. ;-)

> 
> BTW. I'm curious why it is IPv4 fragmentation error, not reassembly. 
> From the trace, looks like dpdk-input node receives two fragmented packets, 
> then try to reassemble them, then fail. Is my understanding not right? 
> Thanks. 

From the trace it looks like it’s the ICMP echo response that’s getting 
fragmented (after the request was reassembled.).

Cheers,
Ole

> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Ole Troan
> Sent: Monday, August 06, 2018 4:35 PM
> To: Ni, Hongjun 
> Cc: vpp-dev ; Hu, Xuekun 
> Subject: Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07
> 
> Looks to me like it’s IPv4 fragmentation that fails, not reassembly.
> Currently fragmentation on buffer chains isn’t supported.
> Try this patch for an ugly hack: https://gerrit.fd.io/r/#/c/13918/
> 
> Cheers,
> Ole
> 
>> On 6 Aug 2018, at 08:34, Ni, Hongjun  wrote:
>> 
>> Hi all,
>> 
>> We performed below test on VPP 18.07, and it seems that IP reassembly 
>> doesn't work in VPP 18.07.
>> 
>> Below is the test topology:
>> Machine A is the VPP DUT, while machine B is just a standard Linux server.
>> Network topology: Machine A (VPP) <> Machine B ; And set both MTU 
>> to 1500
>> Issue: “ping A_ip -s 2000” at B doesn’t get reply from A; While from VPP 
>> (A), “ping B_ip size 1900” does.
>> 
>> Could you help to take a look at this issue?  Thanks a lot.
>> 
>> Below is the configuration and packet trace:
>> VPP CLI: 
>>  set interface state TenGigabitEthernetaf/0/1 up
>>  set interface ip address TenGigabitEthernetaf/0/1 
>> 10.1.1.2/24 set interface mtu 1500 TenGigabitEthernetaf/0/1 set 
>> interface reassembly TenGigabitEthernetaf/0/1 on vpp# show errors
>> 314ip4-fragmalformed packet
>> Vpp# show trace
>> Packet 1
>> 
>> 00:04:02:492398: dpdk-input
>>  TenGigabitEthernetaf/0/1 rx queue 0
>>  buffer 0x2556: current data 14, length 1500, free-list 0, clone-count 0, 
>> totlen-nifb 0, trace 0x0
>> ext-hdr-valid
>> l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>>  PKT MBUF: port 0, nb_segs 1, pkt_len 1514
>>buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128, phys_addr 
>> 0x80095600
>>packet_type 0x391 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>>rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>>Packet Offload Flags
>>  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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
>> extension headers
>>  RTE_PTYPE_L4_FRAG (0x0300) Fragmented IP packet
>>  IP4: 68:05:ca:3a:19:18 -> 3c:fd:fe:a9:cc:ed
>>  ICMP: 10.1.1.1 -> 10.1.1.2
>>tos 0x00, ttl 64, length 1500, checksum 0x2eb6
>>fragment id 0x1067, flags MORE_FRAGMENTS
>>  ICMP echo_request checksum 0x496a
>> 00:04:02:492403: ip4-input-no-checksum
>>  ICMP: 10.1.1.1 -> 10.1.1.2
>>tos 0x00, ttl 64, length 1500, checksum 0x2eb6
>>fragment id 0x1067, flags MORE_FRAGMENTS
>>  ICMP echo_request checksum 0x496a
>> 00:04:02:492406: ip4-reassembly-feature
>>  reass id: 100118, op id: 0 first bi: 9558, data len: 1480, 
>> ip/fragment[0, 1479]
>> new range: [0, 1479], off 0, len 1480, bi 
>> 9558
>>  reass id: 100118, op id: 2 first bi: 9558, data len: 2008, 
>> ip/fragment[0, 1479]
>> finalize reassembly
>> 00:04:02:492434: ip4-lookup
>>  fib 0 dpo-idx 5 flow hash: 0x
>>  ICMP: 10.1.1.1 -> 10.1.1.2
>>tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>>fragment id 0x1067
>>  ICMP echo_request checksum 0x496a
>> 00:04:02:492435: ip4-local
>>ICMP: 10.1.1.1 -> 10.1.1.2
>>  tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>>  fragment id 0x1067
>>ICMP echo_request checksum 0x496a
>> 00:04:02:492436: ip4-icmp-input
>>  ICMP: 10.1.1.1 -> 10.1.1.2
>>tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>>fragment id 0x1067
>>  ICMP echo_request checksum 0x496a
>> 00:04:02:492436: ip4-icmp-echo-request
>>  ICMP: 10.1.1.1 -> 10.1.1.2
>>tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>>fragment id 0x1067
>>  ICMP echo_request checksum 0x496a
>> 00:04:02:492436: ip4-load-balance
>>  fib 0 dpo-idx 13 flow hash: 0x
>>  ICMP: 10.1.1.2 -> 10.1.1.1
>>tos 0x00, ttl 64, length 2028, checksum 0x2d49
>>fragment id 0x2fc4
>>  ICMP echo_reply checksum 0x516a
>> 00:04:02:492436: ip4-rewrite
>>  tx_sw_if_index 0 dpo-idx 1 : ipv4 via 10.1.1.1 TenGigabitEthernetaf/0/1: 
>> mtu:1500 6805ca3a19183cfdfea9cced0800 flow hash: 0x05dc
>>  : 450007ec2fc440012d490a0101020a010101516a3ef600723f805a48
>>  0020: bd7c0c00101112131415161718191a1b1c1d1e1f
>> 00:04:02:492436: ip4-f

Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07

[Xuekun]

Thanks, Ole, your patch works! May consider how to implement an optimized one. 
:-) 

BTW. I'm curious why it is IPv4 fragmentation error, not reassembly. 
From the trace, looks like dpdk-input node receives two fragmented packets, 
then try to reassemble them, then fail. Is my understanding not right? Thanks. 

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ole Troan
Sent: Monday, August 06, 2018 4:35 PM
To: Ni, Hongjun 
Cc: vpp-dev ; Hu, Xuekun 
Subject: Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07

Looks to me like it’s IPv4 fragmentation that fails, not reassembly.
Currently fragmentation on buffer chains isn’t supported.
Try this patch for an ugly hack: https://gerrit.fd.io/r/#/c/13918/

Cheers,
Ole

> On 6 Aug 2018, at 08:34, Ni, Hongjun  wrote:
> 
> Hi all,
>  
> We performed below test on VPP 18.07, and it seems that IP reassembly doesn't 
> work in VPP 18.07.
>  
> Below is the test topology:
> Machine A is the VPP DUT, while machine B is just a standard Linux server.
> Network topology: Machine A (VPP) <> Machine B ; And set both MTU 
> to 1500
> Issue: “ping A_ip -s 2000” at B doesn’t get reply from A; While from VPP (A), 
> “ping B_ip size 1900” does.
>  
> Could you help to take a look at this issue?  Thanks a lot.
>  
> Below is the configuration and packet trace:
> VPP CLI: 
>   set interface state TenGigabitEthernetaf/0/1 up
>   set interface ip address TenGigabitEthernetaf/0/1 
> 10.1.1.2/24 set interface mtu 1500 TenGigabitEthernetaf/0/1 set 
> interface reassembly TenGigabitEthernetaf/0/1 on vpp# show errors
>  314ip4-fragmalformed packet
> Vpp# show trace
> Packet 1
>  
> 00:04:02:492398: dpdk-input
>   TenGigabitEthernetaf/0/1 rx queue 0
>   buffer 0x2556: current data 14, length 1500, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x0
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>   PKT MBUF: port 0, nb_segs 1, pkt_len 1514
> buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128, phys_addr 
> 0x80095600
> packet_type 0x391 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
> extension headers
>   RTE_PTYPE_L4_FRAG (0x0300) Fragmented IP packet
>   IP4: 68:05:ca:3a:19:18 -> 3c:fd:fe:a9:cc:ed
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492403: ip4-input-no-checksum
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492406: ip4-reassembly-feature
>   reass id: 100118, op id: 0 first bi: 9558, data len: 1480, 
> ip/fragment[0, 1479]
>  new range: [0, 1479], off 0, len 1480, bi 
> 9558
>   reass id: 100118, op id: 2 first bi: 9558, data len: 2008, 
> ip/fragment[0, 1479]
>  finalize reassembly
> 00:04:02:492434: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492435: ip4-local
> ICMP: 10.1.1.1 -> 10.1.1.2
>   tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>   fragment id 0x1067
> ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-input
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-echo-request
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-load-balance
>   fib 0 dpo-idx 13 flow hash: 0x
>   ICMP: 10.1.1.2 -> 10.1.1.1
> tos 0x00, ttl 64, length 2028, checksum 0x2d49
> fragment id 0x2fc4
>   ICMP echo_reply checksum 0x516a
> 00:04:02:492436: ip4-rewrite
>   tx_sw_if_index 0 dpo-idx 1 : ipv4 via 10.1.1.1 TenGigabitEthernetaf/0/1: 
> mtu:1500 6805ca3a19183cfdfea9cced0800 flow hash: 0x05dc
>   : 450007ec2fc440012d490a0101020a010101516a3ef600723f805a48
>   0020: bd7c0c00101112131415161718191a1b1c1d1e1f
> 00:04:02:492436: ip4-frag
>   IPv4 offset: 0 mtu: 1500 fragments: 1
> 00:04:02:492437: ip4-drop
> ICMP: 10.1.1.2 -> 10.1.1.1
>   tos 0x00, ttl 64, length 2028, checksum 0x2d49
>   fragment id 0x2fc4
> ICMP echo_reply checksum 0x516a
> 00:04:02:492437: erro

Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07

[Ni, Hongjun]

Thank you Ole ! Will give it a try.

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ole Troan
Sent: Monday, August 6, 2018 4:35 PM
To: Ni, Hongjun 
Cc: vpp-dev ; Hu, Xuekun 
Subject: Re: [vpp-dev] IP reassembly doesn't work in VPP 18.07

Looks to me like it’s IPv4 fragmentation that fails, not reassembly.
Currently fragmentation on buffer chains isn’t supported.
Try this patch for an ugly hack: https://gerrit.fd.io/r/#/c/13918/

Cheers,
Ole

> On 6 Aug 2018, at 08:34, Ni, Hongjun  wrote:
> 
> Hi all,
>  
> We performed below test on VPP 18.07, and it seems that IP reassembly doesn't 
> work in VPP 18.07.
>  
> Below is the test topology:
> Machine A is the VPP DUT, while machine B is just a standard Linux server.
> Network topology: Machine A (VPP) <> Machine B ; And set both MTU 
> to 1500
> Issue: “ping A_ip -s 2000” at B doesn’t get reply from A; While from VPP (A), 
> “ping B_ip size 1900” does.
>  
> Could you help to take a look at this issue?  Thanks a lot.
>  
> Below is the configuration and packet trace:
> VPP CLI: 
>   set interface state TenGigabitEthernetaf/0/1 up
>   set interface ip address TenGigabitEthernetaf/0/1 
> 10.1.1.2/24 set interface mtu 1500 TenGigabitEthernetaf/0/1 set 
> interface reassembly TenGigabitEthernetaf/0/1 on vpp# show errors
>  314ip4-fragmalformed packet
> Vpp# show trace
> Packet 1
>  
> 00:04:02:492398: dpdk-input
>   TenGigabitEthernetaf/0/1 rx queue 0
>   buffer 0x2556: current data 14, length 1500, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x0
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>   PKT MBUF: port 0, nb_segs 1, pkt_len 1514
> buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128, phys_addr 
> 0x80095600
> packet_type 0x391 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
> extension headers
>   RTE_PTYPE_L4_FRAG (0x0300) Fragmented IP packet
>   IP4: 68:05:ca:3a:19:18 -> 3c:fd:fe:a9:cc:ed
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492403: ip4-input-no-checksum
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492406: ip4-reassembly-feature
>   reass id: 100118, op id: 0 first bi: 9558, data len: 1480, 
> ip/fragment[0, 1479]
>  new range: [0, 1479], off 0, len 1480, bi 
> 9558
>   reass id: 100118, op id: 2 first bi: 9558, data len: 2008, 
> ip/fragment[0, 1479]
>  finalize reassembly
> 00:04:02:492434: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492435: ip4-local
> ICMP: 10.1.1.1 -> 10.1.1.2
>   tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>   fragment id 0x1067
> ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-input
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-echo-request
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-load-balance
>   fib 0 dpo-idx 13 flow hash: 0x
>   ICMP: 10.1.1.2 -> 10.1.1.1
> tos 0x00, ttl 64, length 2028, checksum 0x2d49
> fragment id 0x2fc4
>   ICMP echo_reply checksum 0x516a
> 00:04:02:492436: ip4-rewrite
>   tx_sw_if_index 0 dpo-idx 1 : ipv4 via 10.1.1.1 TenGigabitEthernetaf/0/1: 
> mtu:1500 6805ca3a19183cfdfea9cced0800 flow hash: 0x05dc
>   : 450007ec2fc440012d490a0101020a010101516a3ef600723f805a48
>   0020: bd7c0c00101112131415161718191a1b1c1d1e1f
> 00:04:02:492436: ip4-frag
>   IPv4 offset: 0 mtu: 1500 fragments: 1
> 00:04:02:492437: ip4-drop
> ICMP: 10.1.1.2 -> 10.1.1.1
>   tos 0x00, ttl 64, length 2028, checksum 0x2d49
>   fragment id 0x2fc4
> ICMP echo_reply checksum 0x516a
> 00:04:02:492437: error-drop
>   ip4-frag: malformed packet
>  
> Thanks,
> Hongjun
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10040): 
> https://lists.fd.io/g/vpp-dev/message/10040
> Mute This Topic: https

Re: [vpp-dev] [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP artifacts

[Peter Mikus via Lists.Fd.Io]

Hello Vanessa,

For CSIT it is not about release or not. We would need to increase cadence on 
our weekly jobs to daily. Currently CSIT jobs are all failing as VPP has more 
than 10-15 artifacts in week.
Our defined stable versions of VPP (updated once a week) are not in repo 
anymore or are obsoleting faster than we are updating. This is impacting 
everything.

Right now we are *blocked* and we need to work new solution do adopt.

One of the option is that we will have to start building VPP from scratch for 
every job as we cannot use artifacts anymore. This will cause huge overhead on 
infrastructure and execution times will extend as nexus acted as optimization 
for us.
Right now Nexus is not an option for us anymore. This also means that Nexus 
artifacts will not be tested by CSIT.

Peter Mikus
Engineer – Software
Cisco Systems Limited

-Original Message-
From: Vanessa Valderrama via RT [mailto:fdio-helpd...@rt.linuxfoundation.org] 
Sent: Tuesday, July 31, 2018 8:16 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Cc: csit-...@lists.fd.io; infra-steer...@lists.fd.io; vpp-dev@lists.fd.io
Subject: [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP artifacts

Peter,

We need to make a decision on the number of artifacts to keep. I'd like to 
propose the following

previous release repos - 10 packages per subproject master - 10 to 15 packages 
per subproject

Thank you,
Vanessa

On Tue Jun 05 00:51:02 2018, pmi...@cisco.com wrote:
> Hello Vanessa,
> 
> Thank you for an explanation. Indeed this will impact certain things 
> that are planned like "automatic bisecting" (downloading and testing 
> range of artifacts). Let me analyze current situation with CSIT team 
> and get back to you.
> 
> Peter Mikus
> Engineer – Software
> Cisco Systems Limited
> 
> 
> -Original Message-
>  From: Vanessa Valderrama via RT [mailto:fdio- 
> helpd...@rt.linuxfoundation.org]
> Sent: Monday, June 04, 2018 9:47 PM
> To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: csit-...@lists.fd.io; infra-steer...@lists.fd.io; vpp- 
> d...@lists.fd.io
> Subject: [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP 
> artifacts
> 
> Peter,
> 
> The fd.io.master.centos7 repo had to be cleaned up significantly to 
> eliminate Jenkins build timeout errors.  This was discussed in the 
> TSC. Going forward we'll only be keeping an average of 10 of the 
> current release candidate artifacts in the repository.  Please let me 
> know if this retention policy causes an issue for you.
> 
> We do need to clean up the other repositories as well.  Please let me 
> know if you'd like to discuss retention policies.  I'll hold off on 
> cleaning up other repositories for now.
> 
> Thank you,
> Vanessa
> 
> On Wed May 30 10:20:21 2018, pmi...@cisco.com wrote:
> > Hello,
> >
> > I have recently spotted that CentOS repo got reduced and old 
> > binaries are missing [1].
> >
> > Is this expected?
> > Will the similar be done for Ubuntu repos?
> >
> > Was this announced somewhere?
> >
> > Thank you.
> >
> > [1]
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/io/fd/
> > vp
> > p/vpp/
> >
> > Peter Mikus
> > Engineer - Software
> > Cisco Systems Limited
> > [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
> > Think before you print.
> >  This email may contain confidential and privileged material for the  
> > sole use of the intended recipient. Any review, use, distribution or  
> > disclosure by others is strictly prohibited. If you are not the  
> > intended recipient (or authorized to receive for the recipient),  
> > please contact the sender by reply email and delete all copies of 
> > this message.
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 



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

View/Reply Online (#10042): https://lists.fd.io/g/vpp-dev/message/10042
Mute This Topic: https://lists.fd.io/mt/21275985/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] IP reassembly doesn't work in VPP 18.07

[Ole Troan]

Looks to me like it’s IPv4 fragmentation that fails, not reassembly.
Currently fragmentation on buffer chains isn’t supported.
Try this patch for an ugly hack: https://gerrit.fd.io/r/#/c/13918/

Cheers,
Ole

> On 6 Aug 2018, at 08:34, Ni, Hongjun  wrote:
> 
> Hi all,
>  
> We performed below test on VPP 18.07, and it seems that IP reassembly doesn't 
> work in VPP 18.07.
>  
> Below is the test topology:
> Machine A is the VPP DUT, while machine B is just a standard Linux server.
> Network topology: Machine A (VPP) <> Machine B ; And set both MTU to 1500
> Issue: “ping A_ip -s 2000” at B doesn’t get reply from A; While from VPP (A), 
> “ping B_ip size 1900” does.
>  
> Could you help to take a look at this issue?  Thanks a lot.
>  
> Below is the configuration and packet trace:
> VPP CLI: 
>   set interface state TenGigabitEthernetaf/0/1 up
>   set interface ip address TenGigabitEthernetaf/0/1 10.1.1.2/24
> set interface mtu 1500 TenGigabitEthernetaf/0/1
> set interface reassembly TenGigabitEthernetaf/0/1 on
> vpp# show errors
>  314ip4-fragmalformed packet
> Vpp# show trace
> Packet 1
>  
> 00:04:02:492398: dpdk-input
>   TenGigabitEthernetaf/0/1 rx queue 0
>   buffer 0x2556: current data 14, length 1500, free-list 0, clone-count 0, 
> totlen-nifb 0, trace 0x0
>  ext-hdr-valid
>  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
>   PKT MBUF: port 0, nb_segs 1, pkt_len 1514
> buf_len 2176, data_len 1514, ol_flags 0x180, data_off 128, phys_addr 
> 0x80095600
> packet_type 0x391 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
> Packet Offload Flags
>   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_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
> extension headers
>   RTE_PTYPE_L4_FRAG (0x0300) Fragmented IP packet
>   IP4: 68:05:ca:3a:19:18 -> 3c:fd:fe:a9:cc:ed
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492403: ip4-input-no-checksum
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 1500, checksum 0x2eb6
> fragment id 0x1067, flags MORE_FRAGMENTS
>   ICMP echo_request checksum 0x496a
> 00:04:02:492406: ip4-reassembly-feature
>   reass id: 100118, op id: 0 first bi: 9558, data len: 1480, 
> ip/fragment[0, 1479]
>  new range: [0, 1479], off 0, len 1480, bi 
> 9558
>   reass id: 100118, op id: 2 first bi: 9558, data len: 2008, 
> ip/fragment[0, 1479]
>  finalize reassembly
> 00:04:02:492434: ip4-lookup
>   fib 0 dpo-idx 5 flow hash: 0x
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492435: ip4-local
> ICMP: 10.1.1.1 -> 10.1.1.2
>   tos 0x00, ttl 64, length 2028, checksum 0x4ca6
>   fragment id 0x1067
> ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-input
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-icmp-echo-request
>   ICMP: 10.1.1.1 -> 10.1.1.2
> tos 0x00, ttl 64, length 2028, checksum 0x4ca6
> fragment id 0x1067
>   ICMP echo_request checksum 0x496a
> 00:04:02:492436: ip4-load-balance
>   fib 0 dpo-idx 13 flow hash: 0x
>   ICMP: 10.1.1.2 -> 10.1.1.1
> tos 0x00, ttl 64, length 2028, checksum 0x2d49
> fragment id 0x2fc4
>   ICMP echo_reply checksum 0x516a
> 00:04:02:492436: ip4-rewrite
>   tx_sw_if_index 0 dpo-idx 1 : ipv4 via 10.1.1.1 TenGigabitEthernetaf/0/1: 
> mtu:1500 6805ca3a19183cfdfea9cced0800 flow hash: 0x05dc
>   : 450007ec2fc440012d490a0101020a010101516a3ef600723f805a48
>   0020: bd7c0c00101112131415161718191a1b1c1d1e1f
> 00:04:02:492436: ip4-frag
>   IPv4 offset: 0 mtu: 1500 fragments: 1
> 00:04:02:492437: ip4-drop
> ICMP: 10.1.1.2 -> 10.1.1.1
>   tos 0x00, ttl 64, length 2028, checksum 0x2d49
>   fragment id 0x2fc4
> ICMP echo_reply checksum 0x516a
> 00:04:02:492437: error-drop
>   ip4-frag: malformed packet
>  
> Thanks,
> Hongjun
>  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10040): https://lists.fd.io/g/vpp-dev/message/10040
> Mute This Topic: https://lists.fd.io/mt/24206662/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10041): https://li