[vpp-dev] memif issues

[Yao, Chengqiang]

Hi Jakub,

  I’m testing VPP memif and ICMP responder example app. I found there might be 
some issues in extras/libmemif code when it runs in zero-copy mode.

1.   In memif_connect1 function, only the first region is mmaped, while if 
VPP memif runs in zero-copy mode, there will be multiple regions.

2.   icmp_responder-zero-copy-slave sample code will call 
memif_buffer_enq_tx function, but this function has following check that causes 
the failure of this function call:
  if (EXPECT_FALSE (c->args.is_master))
return MEMIF_ERR_INVAL_ARG;

Please kindly check if these issues do exist, thanks.



Best Regards,
Chengqiang Yao


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

View/Reply Online (#10019): https://lists.fd.io/g/vpp-dev/message/10019
Mute This Topic: https://lists.fd.io/mt/24132321/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-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

[Edited Message Follows]

Hi Dave,

It looks like there are significant drops on the receive (rx-miss errors) when 
I use one core. I do not see rx issues with two cores. But, the issue is 
occurring on the transmit side.

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

View/Reply Online (#10018): https://lists.fd.io/g/vpp-dev/message/10018
Mute This Topic: https://lists.fd.io/mt/23982730/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-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

Hi Dave,

It looks like there are significant drops on the receive (rx-miss errors) when 
I use one core. I do not see rx issues with one core. But, the issue is 
occurring on the transmit side.

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

View/Reply Online (#10018): https://lists.fd.io/g/vpp-dev/message/10018
Mute This Topic: https://lists.fd.io/mt/23982730/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-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

Hi Damjan,

> You likely need to utilise RSS on rx side to equally load your cores,
Could you please let me know how I configure RSS?  I do not know how I 
configure RSS because this device is given to vpp/dpdk. It is bound to igb 
driver.
Is it specified in startup.conf or CLI command?

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

View/Reply Online (#10017): https://lists.fd.io/g/vpp-dev/message/10017
Mute This Topic: https://lists.fd.io/mt/23982730/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-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

Hi Yichen,

Thanks for the response. I have issue on the transmit path. I think the cores 
are assigned properly in the configuration.

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

View/Reply Online (#10016): https://lists.fd.io/g/vpp-dev/message/10016
Mute This Topic: https://lists.fd.io/mt/23982730/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-errors on VPP controlled dpdk device

[Dave Barach via Lists.Fd.Io]

+1, the aggregate RX rate seems to be around 12 KPPS, the vector rate is small. 
Absent I/O silliness, one core should handle this load with no problem.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
Lists.Fd.Io
Sent: Wednesday, August 1, 2018 4:27 PM
To: chakravarthy.arise...@viasat.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] tx-errors on VPP controlled dpdk device


In VPP packet stays on the same core where it is received in majority of cases.
Handing over packet to different core is performance expensive process and we 
are trying to avoid it.
You likely need to utilise RSS on rx side to equally load your cores,
but in this specific case VPP is not overloaded, your vector rate is ~2

--
Damjan


On 1 Aug 2018, at 20:22, 
chakravarthy.arise...@viasat.com wrote:

Hi Damjan,

Thanks for your feedback. I'm running the test in AWS instances. Thus, I have 
got only VFs. I do not have access to PF. So, I'm trying to get help from AWS 
to find out.
Once I get the info, I'll post it over here. In the mean time, I looked at the 
counters that you suggested me to focus on. It looks like the packets are 
scheduled on only one core in transmit direction. Is there a way to change?

I have 3 dedicated cores (1 main core thread for stats/mgmt and 2 cores for the 
worker threads). All the Tx queues are pinned to worker thread 1. So, worker 
thread 2 is not used for transmit path at all. Is there way to spread the 
transmit queues across the threads?

Thanks
Chakri
vpp# sh threads
ID NameTypeLWPSched Policy (Priority)  
lcore  Core   Socket State
0  vpp_main  1733other (0)1 
 1  0
1  vpp_wk_0workers 1745other (0)2  
2  0
2  vpp_wk_1workers 1746other (0)3  
3  0
3   stats 1747other (0) 
   0  0  0

vpp# sh run
Thread 0 vpp_main (lcore 1)
Time 5125.9, average vectors/node 0.00, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
api-rx-from-ringany wait 0   0  
   364  1.19e40.00
cdp-process any wait 0   0  
   992  1.98e30.00
dhcp-client-process any wait 0   0  
51  3.41e30.00
dns-resolver-processany wait 0   0  
 5  4.06e30.00
dpdk-processany wait 0   0  
  1709  5.13e40.00
fib-walkany wait 0   0  
  2563  1.37e30.00
ikev2-manager-process   any wait 0   0  
  5124  7.25e20.00
ip-route-resolver-process   any wait 0   0  
51  2.64e30.00
ip4-reassembly-expire-walk  any wait 0   0  
   513  3.85e30.00
ip6-icmp-neighbor-discovery-ev  any wait 0   0  
  5124  6.92e20.00
ip6-reassembly-expire-walk  any wait 0   0  
   513  3.84e30.00
lisp-retry-service  any wait 0   0  
  2563  1.57e30.00
memif-process   any wait 0   0  
  1709  2.10e30.00
rd-cp-process   any wait 0   0  
 237212380  3.21e20.00
unix-cli-local:17active  0   0  
   580  2.05e50.00
unix-epoll-input polling  96172305   0  
 0  1.19e40.00
vpe-oam-process any wait 0   0  
  2513  1.23e30.00
---
Thread 1 vpp_wk_0 (lcore 2)
Time 5125.9, average vectors/node 4.82, last 128 main loops 0.00 per node 0.00
  vector rates in 9.5578e3, out 8.4052e3, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
VirtualFunctionEthernet0/6/0-o   active 91  91  
 0  8.59e21.00
VirtualFunctionEthernet0/6/0-t   active 91  91  
 0  

Re: [vpp-dev] tx-errors on VPP controlled dpdk device

[Yichen Wang via Lists.Fd.Io]

Hi, Chakri,

You can change the VPP worker assignments by doing:
vpp# show interface rx-placement
vpp# set interface rx-placement ?
  set interface rx-placement   set interface rx-placement 
 [queue ] [worker  | main]

Thanks very much!

Regards,
Yichen

From:  on behalf of "chakravarthy.arise...@viasat.com" 

Date: Wednesday, August 1, 2018 at 11:22 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] tx-errors on VPP controlled dpdk device

Hi Damjan,

Thanks for your feedback. I'm running the test in AWS instances. Thus, I have 
got only VFs. I do not have access to PF. So, I'm trying to get help from AWS 
to find out.
Once I get the info, I'll post it over here. In the mean time, I looked at the 
counters that you suggested me to focus on. It looks like the packets are 
scheduled on only one core in transmit direction. Is there a way to change?

I have 3 dedicated cores (1 main core thread for stats/mgmt and 2 cores for the 
worker threads). All the Tx queues are pinned to worker thread 1. So, worker 
thread 2 is not used for transmit path at all. Is there way to spread the 
transmit queues across the threads?

Thanks
Chakri
vpp# sh threads
ID NameTypeLWPSched Policy (Priority)  
lcore  Core   Socket State
0  vpp_main  1733other (0)1 
 1  0
1  vpp_wk_0workers 1745other (0)2  
2  0
2  vpp_wk_1workers 1746other (0)3  
3  0
3   stats 1747other (0) 
   0  0  0

vpp# sh run
Thread 0 vpp_main (lcore 1)
Time 5125.9, average vectors/node 0.00, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
api-rx-from-ringany wait 0   0  
   364  1.19e40.00
cdp-process any wait 0   0  
   992  1.98e30.00
dhcp-client-process any wait 0   0  
51  3.41e30.00
dns-resolver-processany wait 0   0  
 5  4.06e30.00
dpdk-processany wait 0   0  
  1709  5.13e40.00
fib-walkany wait 0   0  
  2563  1.37e30.00
ikev2-manager-process   any wait 0   0  
  5124  7.25e20.00
ip-route-resolver-process   any wait 0   0  
51  2.64e30.00
ip4-reassembly-expire-walk  any wait 0   0  
   513  3.85e30.00
ip6-icmp-neighbor-discovery-ev  any wait 0   0  
  5124  6.92e20.00
ip6-reassembly-expire-walk  any wait 0   0  
   513  3.84e30.00
lisp-retry-service  any wait 0   0  
  2563  1.57e30.00
memif-process   any wait 0   0  
  1709  2.10e30.00
rd-cp-process   any wait 0   0  
 237212380  3.21e20.00
unix-cli-local:17active  0   0  
   580  2.05e50.00
unix-epoll-input polling  96172305   0  
 0  1.19e40.00
vpe-oam-process any wait 0   0  
  2513  1.23e30.00
---
Thread 1 vpp_wk_0 (lcore 2)
Time 5125.9, average vectors/node 4.82, last 128 main loops 0.00 per node 0.00
  vector rates in 9.5578e3, out 8.4052e3, drop 0.e0, punt 0.e0
 Name State Calls  Vectors
Suspends Clocks   Vectors/Call
VirtualFunctionEthernet0/6/0-o   active 91  91  
 0  8.59e21.00
VirtualFunctionEthernet0/6/0-t   active 91  91  
 0  2.82e31.00
VirtualFunctionEthernet0/7/0-o   active533416432661561  
 0  4.33e16.12
VirtualFunctionEthernet0/7/0-t   active533416426753703  
 0  3.83e25.02
arp-inputactive182 182  
 0  7.25e3

Re: [vpp-dev] tx-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

Hi Damjan,

Thanks for your feedback. I'm running the test in AWS instances. Thus, I have 
got only VFs. I do not have access to PF. So, I'm trying to get help from AWS 
to find out.
Once I get the info, I'll post it over here. In the mean time, I looked at the 
counters that you suggested me to focus on. It looks like the packets are 
scheduled on only one core in transmit direction. Is there a way to change?

I have 3 dedicated cores (1 main core thread for stats/mgmt and 2 cores for the 
worker threads). All the Tx queues are pinned to worker thread 1. So, worker 
thread 2 is not used for transmit path at all. Is there way to spread the 
transmit queues across the threads?

Thanks
Chakri

vpp# sh threads
ID     Name                Type            LWP    Sched Policy (Priority)  
lcore  Core   Socket State
0      vpp_main                              1733    other (0)                1 
     1      0
1      vpp_wk_0            workers     1745    other (0)                2      
2      0
2      vpp_wk_1            workers     1746    other (0)                3      
3      0
3                                   stats         1747    other (0)             
   0      0      0

vpp# sh run
Thread 0 vpp_main (lcore 1)
Time 5125.9, average vectors/node 0.00, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 0.e0, drop 0.e0, punt 0.e0
             Name                 State         Calls          Vectors        
Suspends         Clocks       Vectors/Call
api-rx-from-ring                any wait                 0               0      
       364          1.19e4            0.00
cdp-process                     any wait                 0               0      
       992          1.98e3            0.00
dhcp-client-process             any wait                 0               0      
        51          3.41e3            0.00
dns-resolver-process            any wait                 0               0      
         5          4.06e3            0.00
dpdk-process                    any wait                 0               0      
      1709          5.13e4            0.00
fib-walk                        any wait                 0               0      
      2563          1.37e3            0.00
ikev2-manager-process           any wait                 0               0      
      5124          7.25e2            0.00
ip-route-resolver-process       any wait                 0               0      
        51          2.64e3            0.00
ip4-reassembly-expire-walk      any wait                 0               0      
       513          3.85e3            0.00
ip6-icmp-neighbor-discovery-ev  any wait                 0               0      
      5124          6.92e2            0.00
ip6-reassembly-expire-walk      any wait                 0               0      
       513          3.84e3            0.00
lisp-retry-service              any wait                 0               0      
      2563          1.57e3            0.00
memif-process                   any wait                 0               0      
      1709          2.10e3            0.00
rd-cp-process                   any wait                 0               0      
 237212380          3.21e2            0.00
unix-cli-local:17                active                  0               0      
       580          2.05e5            0.00
unix-epoll-input                 polling          96172305               0      
         0          1.19e4            0.00
vpe-oam-process                 any wait                 0               0      
      2513          1.23e3            0.00
---
Thread 1 vpp_wk_0 (lcore 2)
Time 5125.9, average vectors/node 4.82, last 128 main loops 0.00 per node 0.00
  vector rates in 9.5578e3, out 8.4052e3, drop 0.e0, punt 0.e0
             Name                 State         Calls          Vectors        
Suspends         Clocks       Vectors/Call
VirtualFunctionEthernet0/6/0-o   active                 91              91      
         0          8.59e2            1.00
VirtualFunctionEthernet0/6/0-t   active                 91              91      
         0          2.82e3            1.00
VirtualFunctionEthernet0/7/0-o   active            5334164        32661561      
         0          4.33e1            6.12
VirtualFunctionEthernet0/7/0-t   active            5334164        26753703      
         0          3.83e2            5.02
arp-input                        active                182             182      
         0          7.25e3            1.00
dpdk-input                       polling       16550217513        16330917      
         0          4.05e5            0.00
ethernet-input                   active            5334255        32661652      
         0          7.97e1            6.12
interface-output                 active                182             182      
         0          6.58e2            1.00
ip4-input                        active            4685453        16330735   

Re: [vpp-dev] [discuss] vpp region init fail Couldn't connect to vpe, exiting...

[Florin Coras]

Probably the right list would be vpp-...@fd.io . 

As for your question, is vpp actually up and running? What does ps -ef | grep 
vpp show?

Florin

> On Aug 1, 2018, at 10:40 AM, jkzcristiano  wrote:
> 
> Hi all,
> 
> This is the first time I write to this group and I am completely novel to 
> vpp, so sorry if I write in the wrong list. I will share with you the 
> following issue so you might guess what is happening.
> 
> I am starting a virtual machine (VM) in OpenStack using cloud trusty Ubuntu 
> image (http://cloud-images.ubuntu.com/ ).
> 
> This VM is a packet generator so let us named it as 'vPG VM'.
> 
> During VM initiallization, the following bash scripts are also executed:
> 
> 'v_vpacketgen_install.sh' which calls  'v_vpacketgen_init.sh'
> 
> (scripts can be found here 
> https://nexus.onap.org/content/sites/raw/org.onap.demo/vnfs/vfw/1.2.1/ 
> )
> 
> For instance, this is exactly where vpp appears in the scripts
> 
>  # Start VPP
> start vpp
> sleep 1
> 
> # Configure VPP
> IPADDR1=$(ifconfig eth1 | grep "inet addr" | tr -s ' ' | cut -d' ' -f3 | cut 
> -d':' -f2)
> HWADDR1=$(ifconfig eth1 | grep HWaddr | tr -s ' ' | cut -d' ' -f5)
> FAKE_HWADDR1=$(echo -n 00; dd bs=1 count=5 if=/dev/urandom 2>/dev/null | 
> hexdump -v -e '/1 ":%02X"')# Generate a random MAC
> PROTECTED_NET_CIDR=$(cat /opt/config/protected_net_cidr.txt)
> FW_IPADDR=$(cat /opt/config/fw_ipaddr.txt)
> SINK_IPADDR=$(cat /opt/config/sink_ipaddr.txt)
> 
> IPADDR1_MASK=$(ifconfig eth1 | grep "Mask" | awk '{print $4}' | awk -F ":" 
> '{print $2}')
> IPADDR1_CIDR=$(mask2cidr $IPADDR1_MASK)
> 
> ifconfig eth1 down  # Needed to change the MAC
> ifconfig eth1 hw ether $FAKE_HWADDR1# Change eth1 MAC with the random MAC
> ip addr flush dev eth1  # Remove all IP information of an 
> interface
> ifconfig eth1 up
> vppctl tap connect tap111 hwaddr $HWADDR1   # In this 
> sentence, the error occurs
> vppctl set int ip address tap-0 $IPADDR1"/"$IPADDR1_CIDR# Again, in this 
> sentence, the error occurs
> vppctl set int state tap-0 up   # Again, in this 
> sentence, the error occurs
> brctl addbr br0
> brctl addif br0 tap111
> brctl addif br0 eth1
> ifconfig br0 up
> vppctl ip route add $PROTECTED_NET_CIDR via $FW_IPADDR  # Again, in this 
> sentence, the error occurs
> sleep 1
> 
> The following error appears in the logs of the VM every time a vppctl 
> sentence is executed
> 
>  vl_map_shmem:381: region init fail
> connect_to_vlib_internal:123: vl_client_api map rv -2
> Couldn't connect to vpe, exiting...
> 
> I attached with you the OpenStack log of the VM when is created.
> 
> Once the VM completes the initialization process, if I ssh into the VM and 
> try to execute any vpp command (e.g., vppctl show hardware) the console waits 
> for long and then outputs the same above error.
> Do you have any guess of what is happening?
> 
> Kind regards,
> 
> Xoan
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#530): https://lists.fd.io/g/discuss/message/530
> Mute This Topic: https://lists.fd.io/mt/24050397/675152
> Group Owner: discuss+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/discuss/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#10011): https://lists.fd.io/g/vpp-dev/message/10011
Mute This Topic: https://lists.fd.io/mt/24055536/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] CSIT - sw_interface_set_flags admin-up link-up failing

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

> VPP is not crashing so no core dump are available.

I tried to use "gcore" command to create a core dump from running VPP.
So far I got this [0] archive, compressed to around 25 MB,
but the core file inside is around 160 GB big.

Not sure how to make it smaller, even with small numbers
in startup.conf, the core file has around 140 GB.

Vratko.

[0] 
https://jenkins.fd.io/sandbox/job/csit-vpp-perf-verify-master-2n-skx/13/artifact/archive/DUT1_cores.tar.xz

-Original Message-
From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Sent: Tuesday, 2018-July-31 13:25
To: Ray Kinsella ; vpp-dev@lists.fd.io
Cc: csit-...@lists.fd.io; Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at 
Cisco) ; yulong@intel.com
Subject: RE: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

Hello,

Thanks to Vratko (cc), he tested latest master with DPDK 18.02.2 [0]. The issue 
is there as well.

I cannot confirm if "no JSON data.VAT" is related. The bad thing is that there 
is no meaningful return message with more verbose output.

(we do see this on pretty much on all NIC cards in LF and all TBs)

[0] 
https://jenkins.fd.io/sandbox/job/vpp-csit-verify-hw-perf-master-2n-skx/6/consoleFull

Peter Mikus
Engineer – Software
Cisco Systems Limited

-Original Message-
From: Ray Kinsella [mailto:m...@ashroe.eu]
Sent: Tuesday, July 31, 2018 12:06 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; yulong@intel.com
Subject: Re: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

Hi Peter,

It may be unrelated, but I think we see this issue also pretty regularly with 
FD.io VPP 18.04 and the x520, on our local test rig.

The error we typically see is "VAT command sw_interface_set_flags sw_if_index 1 
admin-up: no JSON data.VAT".

Do think it is the same or a separate issue?

Ray K


On 30/07/2018 08:02, Peter Mikus via Lists.Fd.Io wrote:
> Hello vpp-dev,
> 
> I am looking for consultation. We started to test VPP for report on 
> all LF CSIT testbeds Skylakes and Haswells.
> 
> We are observing weird behavior. In each test we are using sequence to 
> first bring the both interfaces (physical up) by VAT:
> 
>    sw_interface_set_flags sw_if_index  admin-up (I 
> also tried sw_interface_set_flags sw_if_index idx admin-up link-up)
> 
> After setting all interfaces UP we are testing if interfaces are 
> really UP by VAT (loop 30times, 1s between API call check): 
> “sw_interface_dump”.
> 
> It wasn’t an issue in past but recently we start seeing that 
> sw_interface_dump is reporting interfaces as link_down (admin-up).
> 
> Notes/symptoms:
> 
> -Our sw_interface_dump check is running 30x (1s interval) in loop.
> 
> -Link-down is random, sometimes both interfaces are link-up sometimes 
> just one and sometimes both link are down.
> 
> -_It is not TB related_, nor cabling related, we see it on 
> Haswells-3node in like 1 out of 70 tests, Skylakes-2node 1 out of 70, 
> but on Skylake-3node more than half of the tests.
> 
> -Checking state during test reveals that interfaces are link-down 
> (show
> int) so “sw_interface_dump” is reporting state correctly.
> 
> -Doing CLI during test “set interface state … up” does bring 
> interfaces UP -> (but it is hard to check the timing here).
> 
> -Affected are mostly x520 and x710, but that is most probably because 
> of statistics (low coverage of other NICs like xxv710 and xl710).
> 
> -We have seen this in master vpp as well as rc2 vpp.
> 
> -It is not clear when this starts to happen, so bisecting would take 
> lot of time.
> 
> -This was spotted on VIRL as well also on Memif interface which bring 
> us to suspicious that this is related to API not HW.
> 
> Do you have an idea what we could check further? VPP is not crashing 
> so no core dump are available. This issue is not 100% replicable which 
> makes it hard to debug.
> 
> Is there a way to get more verbose error from the api call mentioned 
> to reveal more information?
> 
> **
> 
> Thank you.
> 
> *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 (#9967): https://lists.fd.io/g/vpp-dev/message/9967
> Mute This Topic: https://lists.fd.io/mt/23857615/675355
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 

Re: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

[Neale Ranns via Lists.Fd.Io]

Hi Juraj,

How many parallel compiles do you have? What’s the j factor

/neale



From:  on behalf of Juraj Linkeš 

Date: Wednesday, 1 August 2018 at 16:59
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Large memory spike during make verify on ARM machine ThunderX

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

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

[vpp-dev] Large memory spike during make verify on ARM machine ThunderX

[Juraj Linkeš]

Hi vpp-devs,

I noticed that during a specific portion of make verify build on an ARM 
ThunderX machine the build consumes a lot of memory - around 25GB. I can 
identify the spot in the logs:
Jul 31 03:12:48   CXX  gbp_contract.lo

25GB memory hog

Jul 31 03:16:13   CXXLDlibvom.la

but not much else. I created a ticket which 
contains some more information. I didn't see this memory spike when trying to 
reproducing the behavior on my x86 laptop. Does anyone has any idea what could 
be the cause or how to debug this?

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

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

Re: [SUSPICIOUS] Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

You probably want:
ip route add 
192.168.23.3/32
 via TenGigabitEthernet4/0/1 out-labels imp-null

given that 192.168.23.2 is directly connected. We talked before about why 
labels for resolving routes are needed. Here it is again ;)

“
If you want to resolve a recursive path that has outgoing labels, ie.
  via 1.1.1.1 out-labels 33

then the resolving route in the FIB MUST also have out-labels. This is because 
you are in effect layering LSPs (the tunnel is the upper/inner layer and the 
route the lower/outer layer). The out-label for the tunnel, provided by the 
tunnel egress device, is not necessarily directly connected to the tunnel 
ingress device. Hence, if the route did not have an out label then a device in 
between the two (that is in the lower layer) would see the label for the 
tunnel/upper layer and mis-forward.
If your two devices are directly connected and so the problem above cannot 
occur, you still need an out-label for the route, but one describes such 
directly connectivity by giving the route an implicit-null out-label, i.e.
   ip route 1.1.1.1/32  via 192.168.1.1 GigabitEthernet13/0/0 out-label imp-null

“

where you replace ‘tunnel’ with ‘recursive route’.

Regards,
nelae


From:  on behalf of Gulakh 
Date: Wednesday, 1 August 2018 at 14:03
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: [SUSPICIOUS] Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

Yes, that's right, the problem fixed. I should have inserted this rule : "ip 
route add 
192.168.23.3/32
 via TenGigabitEthernet4/0/1 out-labels 50"

But why doesn't work if I don't have a MPLS label for 
192.168.23.3/32
 ? suppose that the Core of the network is pure IP, no MPLS. I know that in 
L3VPN we need a MPLS enabled core but for the sake of IP resolution in another 
FIB, why does it need a second label i.e. MPLS label??

On Tue, Jul 31, 2018 at 5:54 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi,

Please show me:
  sh ip fib index 1 
5.5.5.5/32
and
  sh ip fib index 0 
192.168.23.3/32

I suspect you are missing an out-label on the latter.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Tuesday, 31 July 2018 at 14:53
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

It seems that the Next hop IP resolution does not work correctly:
Here is my Configuration:

# set interface state GigabitEthernet4/0/0 up
# set interface state GigabitEthernet4/0/1 up

# ip table add 1   (create Customer VRF)

# set interface ip table GigabitEthernet 4/0/0 1  (Customer VRF)

# set interface ip address GigabitEthernet4/0/0 
192.168.12.2/24
   

Re: [vpp-dev] Error in VPP DPDK plugin api

[Rubina Bianchi]

Thanks for your prompt answer

As you mentioned I checked your clue and I find out that there is no #define 
REPLY_MSG_ID_BASE in dpdk plugin. So I added #define REPLY_MSG_ID_BASE 
dpdk_main.msg_id_base and my first problem solved.

So what's your opinion on my second question in my first email?

From: Dave Barach (dbarach) 
Sent: Wednesday, August 1, 2018 2:17 PM
To: Rubina Bianchi; vpp-dev@lists.fd.io
Subject: RE: Error in VPP DPDK plugin api


Seems like you may have forgotten to add my_main->msg_id_base to mp->_vl_msg_id 
when sending the reply message from your data plane plugin.



From: vpp-dev@lists.fd.io  On Behalf Of Rubina Bianchi
Sent: Wednesday, August 1, 2018 6:42 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Error in VPP DPDK plugin api



Hi Dear VPP



I added an api to DPDK plugin in VPP src/plugin/dpdk.

My api functionality is OK but my reply handler is never called 
(_reply_t_handler is implemented for api and its function signature added to 
foreach_api_msg).

When I call my api in vpp_api_test, it returns "msg_handler_internal:432: no 
handler for msg id 9" and it doesn't return retval (its job is done correctly, 
just reply has problem).



How could I fix this warning?



I also developed a client based on dpdk_test.c like as VAT, but I faced with 
missing "dpdk/api/dpdk.api.h". I checked /usr/include/vpp and /usr/include/dpdk 
and didn't find missed header. So I added dpdk/api/dpdk.api.h to 
nobase_include_HEADERS in VPP src/plugins/dpdk.am.



What is the best solution? Do you think my approach to handle it, is right?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10006): https://lists.fd.io/g/vpp-dev/message/10006
Mute This Topic: https://lists.fd.io/mt/24003854/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] Error in VPP DPDK plugin api

[Dave Barach via Lists.Fd.Io]

Seems like you may have forgotten to add my_main->msg_id_base to mp->_vl_msg_id 
when sending the reply message from your data plane plugin.

From: vpp-dev@lists.fd.io  On Behalf Of Rubina Bianchi
Sent: Wednesday, August 1, 2018 6:42 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Error in VPP DPDK plugin api

Hi Dear VPP

I added an api to DPDK plugin in VPP src/plugin/dpdk.
My api functionality is OK but my reply handler is never called 
(_reply_t_handler is implemented for api and its function signature added to 
foreach_api_msg).
When I call my api in vpp_api_test, it returns "msg_handler_internal:432: no 
handler for msg id 9" and it doesn't return retval (its job is done correctly, 
just reply has problem).

How could I fix this warning?

I also developed a client based on dpdk_test.c like as VAT, but I faced with 
missing "dpdk/api/dpdk.api.h". I checked /usr/include/vpp and /usr/include/dpdk 
and didn't find missed header. So I added dpdk/api/dpdk.api.h to 
nobase_include_HEADERS in VPP src/plugins/dpdk.am.

What is the best solution? Do you think my approach to handle it, is right?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

[Gulakh]

Yes, that's right, the problem fixed. I should have inserted this rule : "*ip
route add 192.168.23.3/32  via
TenGigabitEthernet4/0/1 out-labels 50*"

But why doesn't work if I don't have a MPLS label for 192.168.23.3/32 ?
suppose that the Core of the network is pure IP, no MPLS. I know that in
L3VPN we need a MPLS enabled core but for the sake of IP resolution in
another FIB, why does it need a second label i.e. MPLS label??

On Tue, Jul 31, 2018 at 5:54 PM, Neale Ranns (nranns) 
wrote:

> Hi,
>
>
>
> Please show me:
>
>   sh ip fib index 1 5.5.5.5/32
>
> and
>
>   sh ip fib index 0 192.168.23.3/32
>
>
>
> I suspect you are missing an out-label on the latter.
>
>
>
> /neale
>
>
>
> *From: * on behalf of Gulakh 
> *Date: *Tuesday, 31 July 2018 at 14:53
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[SUSPICIOUS] [vpp-dev] L3VPN in VPP
>
>
>
> It seems that the Next hop IP resolution does not work correctly:
>
> Here is my Configuration:
>
>
>
> # *set interface state GigabitEthernet4/0/0 up*
>
> # *set interface state GigabitEthernet4/0/1 up*
>
>
>
> #* ip table add 1   *(create Customer VRF)
>
>
>
> # *set interface ip table GigabitEthernet 4/0/0 1*  (Customer VRF)
>
>
>
> # *set interface ip address GigabitEthernet4/0/0 192.168.12.2/24
> *
>   (Toward Customer)
>
> # *set interface ip address GigabitEthernet4/0/1 192.168.23.2/24
> *
>   (Toward Core)
>
>
>
> *** Now I want to add one of Customer's route into its VRF:
>
> # *ip route add 5.5.5.5/32
> 
> table 1 via 192.168.23.3 next-hop-table 0 out-labels 40*
>
>
>
> in which :* 5.5.5.5/32
> *
> is the Customer's another site in somewhere else
>
>   * table 1* is the customer's VRF
>
>*192.168.23.3* is the next hop which is in the core -> be
> resolved by Global VRF
>
>*next-hop-table 0* is the Global VRF to resolve
> 192.168.23.3
>
>*out-labels 40 *is the VPN Label
>
>
>
>
>
> Now When I see the VRF 1 ("*show ip fib table 1*"), here is the output
> for 5.5.5.5/32
> 
>
>
>
> ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ]
> locks:[src:CLI:2, ]
>
> ..
>
> ...
>
> 
>
> 192.168.12.0/24
> 
>   unicast-ip4-chain
>   [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:13 to:[0:0]]
> [0] [@4]: ipv4-glean: GigabitEthernet4/0/0: mtu:9000
> a0369f23aa780806
>
>
>
>
> *5.5.5.5/32
> 

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

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

Vanessa,

does it apply to all fd.io projects or only VPP?

Regards,
Marek

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Vanessa 
Valderrama via RT
Sent: 31 lipca 2018 20:16
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: [vpp-dev] [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 (#10003): https://lists.fd.io/g/vpp-dev/message/10003
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Error in VPP DPDK plugin api

[Rubina Bianchi]

Hi Dear VPP

I added an api to DPDK plugin in VPP src/plugin/dpdk.
My api functionality is OK but my reply handler is never called 
(_reply_t_handler is implemented for api and its function signature added to 
foreach_api_msg).
When I call my api in vpp_api_test, it returns "msg_handler_internal:432: no 
handler for msg id 9" and it doesn't return retval (its job is done correctly, 
just reply has problem).

How could I fix this warning?

I also developed a client based on dpdk_test.c like as VAT, but I faced with 
missing "dpdk/api/dpdk.api.h". I checked /usr/include/vpp and /usr/include/dpdk 
and didn't find missed header. So I added dpdk/api/dpdk.api.h to 
nobase_include_HEADERS in VPP src/plugins/dpdk.am.

What is the best solution? Do you think my approach to handle it, is right?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10002): https://lists.fd.io/g/vpp-dev/message/10002
Mute This Topic: https://lists.fd.io/mt/24003854/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-errors on VPP controlled dpdk device

[Damjan Marion via Lists.Fd.Io]

Try to dump hardware counters with "show hardware"
That my give you more information what's wrong...

As you are using VF, my wild guess is that you may have promisc mode disabled. 
Try to dump PF
details with 'ip link show dev XXX"

-- 
Damjan

> On 1 Aug 2018, at 00:52, chakravarthy.arise...@viasat.com wrote:
> 
> Hi,
> 
> When VPP is sending out the traffic through DPDK device, it encounters 
> transmit errors? Can someone shed some light what might be happening?
> 
> Thanks
> Chakri
> 
> vpp# show int
>   Name   Idx   State  Counter  
> Count
> VirtualFunctionEthernet0/6/0  1 up   rx packets  
> 21141847
>  rx bytes 
> 33657724324
>  tx packets   
>  62
>  tx bytes 
>2604
>  ip4 
> 21141785
> VirtualFunctionEthernet0/7/0  2 up   rx packets   
>  62
>  rx bytes 
>2604
>  tx packets  
> 21141847
>  tx bytes 
> 33657724324
>  tx-error 
> 3675066
> local00 up
> loop1 3 up
> loop2 5 up
> memif1/1  7 up   tx packets  
> 21141785
>  tx bytes 
> 32600632470
> memif2/2  8 up   rx packets  
> 21141785
>  rx bytes 
> 32600632470
> vxlan_tunnel1 4 up   rx packets  
> 21141785
>  rx bytes 
> 32600632470
> vxlan_tunnel2 6 up   tx packets  
> 21141785
>  tx bytes 
> 33361736730
> vpp# sh error
>CountNode  Reason
>   10570865  vxlan4-input  good packets decapsulated
>   21141785  vxlan4-encap  good packets encapsulated
>   31712650l2-output   L2 output packets
>   31712650l2-learnL2 learn packets
>   31712650l2-inputL2 input packets
>126arp-input   ARP replies sent
>3675066 VirtualFunctionEthernet0/7/0-txTx packet drops (dpdk tx 
> failure)
>   10570920  vxlan4-input  good packets decapsulated
>   10570920l2-output   L2 output packets
>   10570920l2-learnL2 learn packets
>   10570920l2-inputL2 input packets
> 
> Thread 0 vpp_main (lcore 1)
> Time 957448.6, average vectors/node 1.00, last 128 main loops 0.00 per node 
> 0.00
>   vector rates in 0.e0, out 2.0889e-6, drop 0.e0, punt 0.e0
>  Name State Calls  Vectors
> Suspends Clocks   Vectors/Call
> VirtualFunctionEthernet0/6/0-o   active  1   1
>0  9.65e31.00
> VirtualFunctionEthernet0/6/0-t   active  1   1
>0  2.03e41.00
> VirtualFunctionEthernet0/7/0-o   active  1   1
>0  6.08e31.00
> VirtualFunctionEthernet0/7/0-t   active  1   1
>0  1.11e41.00
> acl-plugin-fa-cleaner-process  event wait0   0
>1  2.51e40.00
> admin-up-down-process  event wait0   0
>1  1.12e30.00
> api-rx-from-ringany wait 0   0
>68101  1.24e40.00
> avf-processevent wait0   0
>1  6.97e30.00
> bfd-processevent wait0   0
>1  1.64e40.00
> cdp-process any wait 0   0
>   127877  2.62e30.00
> dhcp-client-process any wait 0   0
> 9575  3.55e30.00
> 

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

[Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

Vanessa,

does it apply to all fd.io projects or only VPP?

Regards,
Marek

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Vanessa 
Valderrama via RT
Sent: 31 lipca 2018 20:16
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: [vpp-dev] [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 (#1): https://lists.fd.io/g/vpp-dev/message/1
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] [csit-dev] VPP Release 18.07 is out!

[Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES@Cisco) via Lists.Fd.Io]

Congratulations!

From: csit-...@lists.fd.io [mailto:csit-...@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: 31 lipca 2018 04:57
To: vpp-dev ; csit-...@lists.fd.io
Subject: [csit-dev] VPP Release 18.07 is out!

VPP Release 18.07 is out.  Packages are in the usual places.

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

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