Re: [vpp-dev] VCL defaults to app-local-scope

[Alok Nikhil (anikhil) via Lists.Fd.Io]

Great! Thanks Florin.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13523): https://lists.fd.io/g/vpp-dev/message/13523
Mute This Topic: https://lists.fd.io/mt/32435763/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 Jenkins Issue

[Vanessa Valderrama]

We believe this issue is resolved. We had to manually push the jobs to
Jenkins as a solution for now.

We are still investigating the root cause.

I am re-triggering jobs that weren't triggered during this incident.

Thank you,
Vanessa

On 07/17/2019 02:40 PM, Vanessa Valderrama wrote:
> We are currently seeing an issue with Jenkins not displaying
> https://jenkins.fd.io/view/vpp/ correctly. The scenario we are seeing is
> the page spinning and displaying a random number of jobs to different users.
>
> We apologize for the inconvenience. We are investigating this issue and
> will have it resolved as quickly as possible.
>
> Thank you,
> Vanessa
>

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

View/Reply Online (#13522): https://lists.fd.io/g/vpp-dev/message/13522
Mute This Topic: https://lists.fd.io/mt/32507348/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 Jenkins Issue

[Vanessa Valderrama]

We are currently seeing an issue with Jenkins not displaying
https://jenkins.fd.io/view/vpp/ correctly. The scenario we are seeing is
the page spinning and displaying a random number of jobs to different users.

We apologize for the inconvenience. We are investigating this issue and
will have it resolved as quickly as possible.

Thank you,
Vanessa

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

View/Reply Online (#13521): https://lists.fd.io/g/vpp-dev/message/13521
Mute This Topic: https://lists.fd.io/mt/32507348/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] Scheduling VPP 19.01.3 Maintenance Release

[Swati Kher -X (swkher - NETPACE INC at Cisco) via Lists.Fd.Io]

Starting VPP 19.01.3 Maintenance Release now.

VPP Committers, Please do not merge any patches into stable/1901 until after 
the VPP 19.01.3 is complete.

Thanks,


[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/07_standard_graphic.png]




Swati Kher
Engineer - Software
swk...@cisco.com
Tel:










Cisco Systems, Inc.
400 East Tasman Drive
SAN JOSE
95134
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

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.
Please click 
here
 for Company Registration Information.







From: Swati Kher -X (swkher - NETPACE INC at Cisco) 
Sent: Wednesday, July 17, 2019 8:40 AM
To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
Cc: swatik...@gmail.com; Swati Kher -X (swkher - NETPACE INC at Cisco) 

Subject: RE: Scheduling VPP 19.01.3 Maintenance Release

Folks,

As announced at the last VPP community meeting, today we'll be starting the VPP 
19.01.3 Maintenance Release at 1800UTC.

Currently there are no patches in stable/1901 that are not merged.  Please 
unicast me or Dave Wallace if you have a fix that needs to be included in this 
maintenance release.

Thanks,

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/07_standard_graphic.png]




Swati Kher
Engineer - Software
swk...@cisco.com
Tel:










Cisco Systems, Inc.
400 East Tasman Drive
SAN JOSE
95134
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

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.
Please click 
here
 for Company Registration Information.







From: Swati Kher -X (swkher - NETPACE INC at Cisco)
Sent: Friday, July 5, 2019 2:48 PM
To: 'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io>>; 
'csit-...@lists.fd.io' mailto:csit-...@lists.fd.io>>
Cc: 'swatik...@gmail.com' mailto:swatik...@gmail.com>>
Subject: Scheduling VPP 19.01.3 Maintenance Release


We are scheduling a maintenance release for VPP 19.01.3.
This maintenance release is tentatively scheduled for Wednesday, July 17, 2019.

If anyone has any known bug fixes that are required for 19.01 , then please
communicate that so that we can plan on merging these before Wednesday, July 
the 17th.

This plan will be confirmed at the next Tuesday, July 9, 2019 VPP Meeting along 
with any
Questions and concerns. Once this plan is committed, we will follow through 
with the proposed
Release activity.

Thanks,

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/07_standard_graphic.png]




Swati Kher
Engineer - Software
swk...@cisco.com
Tel:










Cisco Systems, Inc.
400 East Tasman Drive
SAN JOSE
95134
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

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.
Please click 
here
 for Company Registration Information.







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

View/Reply Online (#13520): https://lists.fd.io/g/vpp-dev/message/13520
Mute This Topic: https://lists.fd.io/mt/32504639/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] bihash memory fragmentation

[Dave Barach via Lists.Fd.Io]

Try configuring approximately nbuckets = (nitems / BIHASH_KVP_PER_PAGE). Make 
sure that the hash function performs reasonably well on the particular keys 
involved.

The scheme tolerates a mis-sized bucket array - lookup performance won't 
change, to a first approximation - but space utilization becomes an issue as 
you discovered.

In the case at hand: try 64k buckets instead of 1k buckets...

HTH... Dave

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andreas Schultz
Sent: Wednesday, July 17, 2019 11:58 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] bihash memory fragmentation

Hi,

I've run into bihash crashing VPP with an out-of-memory error. After 
investigation I found that the bihash has reached its configured memory limit 
with far less entries that I would have expected.
Some numbers:

Type: bihash_8_8
bihash max. memory: 64MB
Buckets: 1024
Entries 200k

With that number it turns out that almost all buckets have 2^9 pages
(512 pages).
On average 200 entries per bucket are actually used.
The total memory consumption from the buckets and pages should be
1024 * sizeof(bucket) + 1024 * 2^9 * sizeof(page) = 33 MB

Yet the bihash has consumed all 64MB (alloc_arena_next > memory_size).

It turned out that the missing memory was in the freelists for smaller page 
sizes.

I have resized the bihash to have more buckets to avoid the large pages.

Is there anything else I can do?

I was thinking about enhancing bihash to specify a initial page size.
This would waste some memory while the hash is growing, but would later avoid 
the fragmentation. Does that make sense?

Regards
Andreas
--
Andreas Schultz

-- 

Principal Engineer

t: +49 391 819099-224

--- enabling your networks
-

Travelping GmbH

Roentgenstraße 13

39108 Magdeburg

Germany

t: +49 391 819099-0

f: +49 391 819099-299

e: i...@travelping.com

w: https://www.travelping.com/


Company registration: Amtsgericht Stendal  Reg. No.: HRB 10578
Geschaeftsfuehrer: Holger Winkelmann VAT ID: DE236673780
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13519): https://lists.fd.io/g/vpp-dev/message/13519
Mute This Topic: https://lists.fd.io/mt/32504802/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] loopback admin status

[Neale Ranns via Lists.Fd.Io]

Hi Matt,

Sounds like exactly what we need.

/neale

De : Matthew Smith 
Date : mercredi 17 juillet 2019 à 14:52
À : "Neale Ranns (nranns)" 
Cc : vpp-dev 
Objet : Re: [vpp-dev] loopback admin status

Hi Neale,

Thanks for your reply.

I noticed that there is a function for IPv6 named 
ip6_sw_interface_admin_up_down() in src/vnet/ip/ip6_forward.c which seems like 
it iterates the IPv6 addresses on an interface and adds or deletes the routes 
for each address if the interface is brought up or down. So maybe this is 
already handled for IPv6? If I'm understanding that correctly, do you think it 
would be appropriate to add a similar function for IPv4 and register it with 
VNET_SW_INTERFACE_ADMIN_UP_DOWN_FUNCTION()?

-Matt


On Wed, Jul 17, 2019 at 3:33 AM Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:

Hi Matt,

I would tend to agree with you. The interface’s IP addresses should not be 
programmed in the FIB if the interface is down.

/neale


De : mailto:vpp-dev@lists.fd.io>> au nom de "Matthew Smith 
via Lists.Fd.Io" 
mailto:netgate@lists.fd.io>>
Répondre à : "mgsm...@netgate.com" 
mailto:mgsm...@netgate.com>>
Date : mardi 16 juillet 2019 à 21:42
À : vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc : "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] loopback admin status

Hi,

If I create a loopback interface and configure an IP address on it, I am able 
to ping that IP address from another host regardless of whether the admin 
status of the loopback is up or down. Is that intentional? I'm trying to figure 
out if this is something that can be "fixed" or if the current behavior is the 
way it's supposed to be.

If I use a loopback as an endpoint for services and want to take the services 
offline temporarily, it would be convenient to be able to take the interface 
down and have the services effectively be disabled.

-Matt

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

View/Reply Online (#13516): https://lists.fd.io/g/vpp-dev/message/13516
Mute This Topic: https://lists.fd.io/mt/32495454/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] loopback admin status

[Matthew Smith via Lists.Fd.Io]

Hi Neale,

Thanks for your reply.

I noticed that there is a function for IPv6 named
ip6_sw_interface_admin_up_down() in src/vnet/ip/ip6_forward.c which seems
like it iterates the IPv6 addresses on an interface and adds or deletes the
routes for each address if the interface is brought up or down. So maybe
this is already handled for IPv6? If I'm understanding that correctly, do
you think it would be appropriate to add a similar function for IPv4 and
register it with VNET_SW_INTERFACE_ADMIN_UP_DOWN_FUNCTION()?

-Matt


On Wed, Jul 17, 2019 at 3:33 AM Neale Ranns (nranns) 
wrote:

>
>
> Hi Matt,
>
>
>
> I would tend to agree with you. The interface’s IP addresses should not be
> programmed in the FIB if the interface is down.
>
>
>
> /neale
>
>
>
>
>
> *De : * au nom de "Matthew Smith via Lists.Fd.Io"
> 
> *Répondre à : *"mgsm...@netgate.com" 
> *Date : *mardi 16 juillet 2019 à 21:42
> *À : *vpp-dev 
> *Cc : *"vpp-dev@lists.fd.io" 
> *Objet : *[vpp-dev] loopback admin status
>
>
>
> Hi,
>
>
>
> If I create a loopback interface and configure an IP address on it, I am
> able to ping that IP address from another host regardless of whether the
> admin status of the loopback is up or down. Is that intentional? I'm trying
> to figure out if this is something that can be "fixed" or if the current
> behavior is the way it's supposed to be.
>
>
>
> If I use a loopback as an endpoint for services and want to take the
> services offline temporarily, it would be convenient to be able to take the
> interface down and have the services effectively be disabled.
>
>
>
> -Matt
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] EAL: Cannot init memory

[ben eslami]

Dear all,
I want to run QoS on multiple ports using VPP. Below is the output:
--
root@router:~/Router# /usr/bin/vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:361: plugin path
/usr/lib/vpp_plugins:/usr/lib64/vpp_plugins
load_one_plugin:189: Loaded plugin: abf_plugin.so (ACL based Forwarding)
load_one_plugin:189: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:189: Loaded plugin: avf_plugin.so (Intel Adaptive Virtual
Function (AVF) Device Plugin)
load_one_plugin:191: Loaded plugin: cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development
Kit (DPDK))
load_one_plugin:189: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group Based Policy)
load_one_plugin:189: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP messaging)
load_one_plugin:189: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:189: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:189: Loaded plugin: kubeproxy_plugin.so (kube-proxy data
plane)
load_one_plugin:189: Loaded plugin: l2e_plugin.so (L2 Emulation)
load_one_plugin:189: Loaded plugin: lacp_plugin.so (Link Aggregation
Control Protocol)
load_one_plugin:189: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:189: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:189: Loaded plugin: nat_plugin.so (Network Address
Translation)
load_one_plugin:189: Loaded plugin: pppoe_plugin.so (PPPoE)
load_one_plugin:189: Loaded plugin: router.so (router)
load_one_plugin:189: Loaded plugin: srv6ad_plugin.so (Dynamic SRv6 proxy)
load_one_plugin:189: Loaded plugin: srv6am_plugin.so (Masquerading SRv6
proxy)
load_one_plugin:189: Loaded plugin: srv6as_plugin.so (Static SRv6 proxy)
load_one_plugin:189: Loaded plugin: stn_plugin.so (VPP Steals the NIC for
Container integration)
load_one_plugin:189: Loaded plugin: tlsmbedtls_plugin.so (mbedtls based TLS
Engine)
load_one_plugin:189: Loaded plugin: tlsopenssl_plugin.so (openssl based TLS
Engine)
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
dpdk_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
ioam_export_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
flowprobe_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
vxlan_gpe_ioam_export_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
pppoe_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
gtpu_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
cdp_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
lacp_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
udp_ping_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
kubeproxy_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
ioam_trace_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
memif_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
ioam_vxlan_gpe_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
nat_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
ioam_pot_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
stn_test_plugin.so
/usr/bin/vpp[7457]: load_one_vat_plugin:67: Loaded plugin:
acl_test_plugin.so
/usr/bin/vpp[7457]: vlib_pci_bind_to_uio: Skipping PCI device :0a:00.0
as host interface enp10s0 is up
/usr/bin/vpp[7457]: dpdk: EAL init args: -c 7b -n 4 --huge-dir
/run/vpp/hugepages --file-prefix vpp -b :0a:00.0 --master-lcore 0
--socket-mem 64,64
EAL: FATAL: Cannot init memory
-
here is my startup.conf file:
unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
on
}
api-segment {
  gid vpp
}
cpu {
main-core 0
corelist-workers 1
corelist-hqos-threads 3-4,5-6
}
dpdk {
 dev :05:00.0 {
   num-rx-queues 2
   hqos
 }
 dev :05:00.1 {
   num-rx-queues 2
   hqos
 }
}



How am I supposed to run QoS??
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13514): https://lists.fd.io/g/vpp-dev/message/13514
Mute This Topic: https://lists.fd.io/mt/32502286/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] loopback admin status

[Neale Ranns via Lists.Fd.Io]

Hi Matt,

I would tend to agree with you. The interface’s IP addresses should not be 
programmed in the FIB if the interface is down.

/neale


De :  au nom de "Matthew Smith via Lists.Fd.Io" 

Répondre à : "mgsm...@netgate.com" 
Date : mardi 16 juillet 2019 à 21:42
À : vpp-dev 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] loopback admin status

Hi,

If I create a loopback interface and configure an IP address on it, I am able 
to ping that IP address from another host regardless of whether the admin 
status of the loopback is up or down. Is that intentional? I'm trying to figure 
out if this is something that can be "fixed" or if the current behavior is the 
way it's supposed to be.

If I use a loopback as an endpoint for services and want to take the services 
offline temporarily, it would be convenient to be able to take the interface 
down and have the services effectively be disabled.

-Matt

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

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