date:20170523

Re: [vpp-dev] syslog in snat

2017-05-23 Thread Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)

Hi,

Configuration looks good. Did you trigger some event (supported events 
https://wiki.fd.io/view/VPP/SNAT#NAT_IPFIX_logging)?

Regards,
Matus

From: Andrew Taylor [mailto:andrew2016tay...@gmail.com]
Sent: Wednesday, May 24, 2017 7:48 AM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 

Cc: Matt Paska ; vpp-dev@lists.fd.io; Jim Thompson 

Subject: Re: [vpp-dev] syslog in snat

Hi,
I tested IPFIX in snat plugin, but it only create  template packet.

my configuration is:

set ipfix exporter collector 192.168.30.231 src 192.168.30.235
snat ipfix logging src-port 2020
Thanks,

On Wed, May 24, 2017 at 10:15 AM, Matus Fabian -X (matfabia - PANTHEON 
TECHNOLOGIES at Cisco) > wrote:
Hi,

Snat plugin doesn’t support syslog logging, currently support only IPFIX.

Regards,
Matus

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Matt Paska
Sent: Tuesday, May 23, 2017 8:23 PM
To: vpp-dev@lists.fd.io; Jim Thompson 
>
Cc: Andrew Taylor 
>
Subject: Re: [vpp-dev] syslog in snat

Is there further info/docs on using syslog for snat on the wiki? I searched 
through but couldn't find anything.

Thanks.

On Sat, May 13, 2017 at 10:32 PM, Jim Thompson 
> wrote:

On May 13, 2017, at 11:58 PM, Andrew Taylor 
> wrote:

Hi,
Could you please explain what is "Syslog based SNAT login" in Release Plan 17.07

Added here, so you could ask
https://wiki.fd.io/index.php?title=Projects%2Fvpp%2FRelease_Plans%2FRelease_Plan_17.07iff=5072=5071

Is it an alternative option for logging session like IPFIX ?

I suspect this was intended to be “syslog-based SNAT logging”, and that only 
the final ‘g’ is missing.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] syslog in snat

2017-05-23 Thread Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)

Hi,

Snat plugin doesn’t support syslog logging, currently support only IPFIX.

Regards,
Matus

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Matt Paska
Sent: Tuesday, May 23, 2017 8:23 PM
To: vpp-dev@lists.fd.io; Jim Thompson 
Cc: Andrew Taylor 
Subject: Re: [vpp-dev] syslog in snat

Is there further info/docs on using syslog for snat on the wiki? I searched 
through but couldn't find anything.

Thanks.

On Sat, May 13, 2017 at 10:32 PM, Jim Thompson 
> wrote:

On May 13, 2017, at 11:58 PM, Andrew Taylor 
> wrote:

Hi,
Could you please explain what is "Syslog based SNAT login" in Release Plan 17.07

Added here, so you could ask
https://wiki.fd.io/index.php?title=Projects%2Fvpp%2FRelease_Plans%2FRelease_Plan_17.07iff=5072=5071

Is it an alternative option for logging session like IPFIX ?

I suspect this was intended to be “syslog-based SNAT logging”, and that only 
the final ‘g’ is missing.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Running VPP in a non-default network namespace

2017-05-23 Thread Luke, Chris

Ah, I see what you mean.

The issue being that inside the namespace it cannot query the state of the 
Linux-bound interface (whether up/down) since the namespace doesn't have the 
interface. The behavior falls-back to slurping up all ports Linux says doesn't 
exist; this is at least in part to make sure it captures ports already unbound 
from the kernel.

I'd agree this is not acting in the manner of least surprise. Damjan is the 
best person to comment on this and whether a more consistent behavior can be 
crafted. One simple approach might be to detect we're in a namespace and only 
bind detected-down interfaces and explicitly provided PCI ID's.

Chris.

> -Original Message-
> From: Renato Westphal [mailto:ren...@opensourcerouting.org]
> Sent: Tuesday, May 23, 2017 22:01
> To: Luke, Chris 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Running VPP in a non-default network namespace
> 
> Thank you Chris, disabling the DPDK plugin did the trick for me. My plan is to
> use veth/AF_PACKET interfaces only.
> 
> I think I found a small problem in VPP though.
> 
> When you start VPP and the 'dpdk' section of the configuration file is empty,
> DPDK snatches all physical interfaces that are administratively down.
> 
> This works ok when running VPP in the default netns. But when you run VPP
> in a non-default netns, all physical interfaces are snatched regardless of 
> their
> administrative status.
> 
> Could you confirm if this is a bug? This inconsistent behavior was a source of
> confusion to me.
> 
> Best Regards,
> Renato.
> 
> On Tue, May 23, 2017 at 9:00 PM, Luke, Chris 
> wrote:
> > If you're using DPDK and all your physical interfaces are DPDK-capable, then
> it's snatching the PCI device away from Linux. This has nothing to do with
> Linux namespaces; ns can't prevent it from happening because it's working at
> a different layer in the stack. The point of DPDK is to go straight to the
> hardware.
> >
> > The only time Linux namespace interactions come into play with VPP is
> > with interfaces like 'tap' and 'host' (aka af_packet) which use
> > syscalls to manipulate Linux network state (create ports, listen on a
> > raw socket, etc) or anything else that uses Linux networking (console
> > TCP connections, etc)
> >
> > You can either limit which PCI devices VPP asks DPDK to bind to in the dpdk
> section of the config:
> >
> > dpdk {
> >   dev 
> >   ...
> > }
> >
> > or, if only inter-ns is what you want to do, just disable DPDK altogether:
> >
> > plugins {
> >   plugin dpdk_plugin.so { disable }
> > }
> >
> > Chris.
> >
> >
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io
> >> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Renato Westphal
> >> Sent: Tuesday, May 23, 2017 19:38
> >> To: vpp-dev@lists.fd.io
> >> Subject: [vpp-dev] Running VPP in a non-default network namespace
> >>
> >> Hi all,
> >>
> >> For learning purposes, I'm trying to set up a test topology using
> >> multiple instances of VPP running in different network namespaces.
> >>
> >> I see that there's documentation showing how to use VPP as a router
> >> between namespaces, but in all examples I found VPP is always running
> >> in the default network namespace.
> >>
> >> If I try to run VPP in a non-default network namespace, something
> >> weird
> >> happens: all interfaces from the default netns disappear!
> >>
> >> Does anyone know what might be the cause of this?
> >>
> >> I'm using the official vagrant VM (Ubuntu 16.04) and VPP v17.04.1,
> >> and I can see that the same problem occurs on master and on older
> releases as well.
> >>
> >> More details about the issue below.
> >>
> >> 1 - My VPP config:
> >> # cat /etc/vpp/startup.conf
> >> unix {
> >>   nodaemon
> >>   log /tmp/vpp.log
> >>   full-coredump
> >> }
> >>
> >> api-trace {
> >>   on
> >> }
> >>
> >> api-segment {
> >>   gid vpp
> >> }
> >>
> >> 2 - VPP running ok in the default netns:
> >> # vpp -c /etc/vpp/startup.conf
> >> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> >> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control
> >> Lists)
> >> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> >> Development Kit (DPDK))
> >> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per
> >> Packet)
> >> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> >> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> >> addressing for IPv6)
> >> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> >> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> >> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> >> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> >> Deployment on IPv4 Infrastructure (RFC5969))
> >> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
> >> Interface (experimetal))
> >> load_one_plugin:184: Loaded plugin:

Re: [vpp-dev] Running VPP in a non-default network namespace

2017-05-23 Thread Luke, Chris

If you're using DPDK and all your physical interfaces are DPDK-capable, then 
it's snatching the PCI device away from Linux. This has nothing to do with 
Linux namespaces; ns can't prevent it from happening because it's working at a 
different layer in the stack. The point of DPDK is to go straight to the 
hardware.

The only time Linux namespace interactions come into play with VPP is with 
interfaces like 'tap' and 'host' (aka af_packet) which use syscalls to 
manipulate Linux network state (create ports, listen on a raw socket, etc) or 
anything else that uses Linux networking (console TCP connections, etc)

You can either limit which PCI devices VPP asks DPDK to bind to in the dpdk 
section of the config:

dpdk {
  dev 
  ...
}

or, if only inter-ns is what you want to do, just disable DPDK altogether:

plugins {
  plugin dpdk_plugin.so { disable }
}

Chris.


> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Renato Westphal
> Sent: Tuesday, May 23, 2017 19:38
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Running VPP in a non-default network namespace
> 
> Hi all,
> 
> For learning purposes, I'm trying to set up a test topology using multiple
> instances of VPP running in different network namespaces.
> 
> I see that there's documentation showing how to use VPP as a router
> between namespaces, but in all examples I found VPP is always running in
> the default network namespace.
> 
> If I try to run VPP in a non-default network namespace, something weird
> happens: all interfaces from the default netns disappear!
> 
> Does anyone know what might be the cause of this?
> 
> I'm using the official vagrant VM (Ubuntu 16.04) and VPP v17.04.1, and I can
> see that the same problem occurs on master and on older releases as well.
> 
> More details about the issue below.
> 
> 1 - My VPP config:
> # cat /etc/vpp/startup.conf
> unix {
>   nodaemon
>   log /tmp/vpp.log
>   full-coredump
> }
> 
> api-trace {
>   on
> }
> 
> api-segment {
>   gid vpp
> }
> 
> 2 - VPP running ok in the default netns:
> # vpp -c /etc/vpp/startup.conf
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> Development Kit (DPDK))
> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> Deployment on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
> Interface (experimetal))
> load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address
> Translation)
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/snat_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/lb_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/acl_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
> vlib_pci_bind_to_uio: Skipping PCI device :00:03.0 as host interface
> enp0s3 is up
> vlib_pci_bind_to_uio: Skipping PCI device :00:08.0 as host interface
> enp0s8 is up
> vlib_pci_bind_to_uio: Skipping PCI device :00:09.0 as host interface
> enp0s9 is up
> vpp[1180]: dpdk_ipsec_process:239: not enough Cryptodevs, default to
> OpenSSL IPsec
> vpp[1180]: dpdk_lib_init:182: DPDK drivers found no ports...
> vpp[1180]: dpdk_lib_init:186: DPDK drivers found 0 ports...
> vpp[1180]: received signal SIGINT, PC 0x7fad6a98ea37 DPDK physical memory
> layout:
> Segment 0: phys:0x3400, len:8388608, virt:0x7facdbc0, socket_id:0,
> hugepage_sz:2097152, nchannel:0, nrank:0 Segment 1: phys:0x7080,
> len:2097152, virt:0x7facdb80, socket_id:0, hugepage_sz:2097152,
>

Re: [vpp-dev] Question regarding pool_get/pool_put thread safety

2017-05-23 Thread 张东亚

Hi Chris,

Thanks a lot, you explanation solves my concerns clearly.

2017-05-23 21:47 GMT+08:00 Luke, Chris :

> It is not thread safe; it’s up to the caller to be thread safe. Typically
> each thread works on its own memory and objects to avoid cross-thread
> locking or cross-socket cache invalidation.
>
>
>
> Most volatile objects are typically modified by the API or CLI and there’s
> a main thread that hosts these entry points and In effect this serializes
> accesses so that locking/synchronization is much less necessary.
>
>
>
> Where it’s absolutely necessary we use spinlocks to synchronize such
> things but try *really* hard not to.
>
>
>
> Chris.
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *???
> *Sent:* Monday, May 22, 2017 22:38
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] Question regarding pool_get/pool_put thread safety
>
>
>
> Hi folks,
>
>
>
> There is a pool_get and pool_put macro based on vec structure, quite a few
> code rely on that, however, I have a question regarding about the thread
> safety of these two APIs, I do not found any comments for them.
>
>
>
> Since pool_get may resize the vec, is there any issue if another worker
> thread trying to use pool_put which may refer to the old underlying vec?
>
>
>
> Or there is some implicit coding convention to use the two APIs?
>
>
>
> Thanks a lot.
>
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Running VPP in a non-default network namespace

2017-05-23 Thread Renato Westphal

Hi all,

For learning purposes, I'm trying to set up a test topology using
multiple instances of VPP running in different network namespaces.

I see that there's documentation showing how to use VPP as a router
between namespaces, but in all examples I found VPP is always running
in the default network namespace.

If I try to run VPP in a non-default network namespace, something
weird happens: all interfaces from the default netns disappear!

Does anyone know what might be the cause of this?

I'm using the official vagrant VM (Ubuntu 16.04) and VPP v17.04.1, and
I can see that the same problem occurs on master and on older releases
as well.

More details about the issue below.

1 - My VPP config:
# cat /etc/vpp/startup.conf
unix {
  nodaemon
  log /tmp/vpp.log
  full-coredump
}

api-trace {
  on
}

api-segment {
  gid vpp
}

2 - VPP running ok in the default netns:
# vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
Development Kit (DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
Deployment on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
vlib_pci_bind_to_uio: Skipping PCI device :00:03.0 as host
interface enp0s3 is up
vlib_pci_bind_to_uio: Skipping PCI device :00:08.0 as host
interface enp0s8 is up
vlib_pci_bind_to_uio: Skipping PCI device :00:09.0 as host
interface enp0s9 is up
vpp[1180]: dpdk_ipsec_process:239: not enough Cryptodevs, default to
OpenSSL IPsec
vpp[1180]: dpdk_lib_init:182: DPDK drivers found no ports...
vpp[1180]: dpdk_lib_init:186: DPDK drivers found 0 ports...
vpp[1180]: received signal SIGINT, PC 0x7fad6a98ea37
DPDK physical memory layout:
Segment 0: phys:0x3400, len:8388608, virt:0x7facdbc0,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x7080, len:2097152, virt:0x7facdb80,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x70c0, len:257949696, virt:0x7fac7620,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0

3 - Now running VPP in a non-default netns:
root@localhost:~# unshare -n bash
root@localhost:~# vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
Development Kit (DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
Deployment on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin:

Re: [vpp-dev] The Case Of the Missing API Definition

2017-05-23 Thread John Lo (loj)

Hi Jon,

Appreciate your nicely written lament of the missing API. I fully accept your 
point about API changes, especially removal of existing ones, should be given 
heads up in the vpp-dev alias before it merges in the code base.

I merged this change for VPP L2 API as it is a nice cleanup for the response 
generated by VPP for the bridge_domain_details API request.  Prior to this 
cleanup, the response of the request would come back as one API message for 
bridge_domain_details, which includes a field n_sw_ifs about number of 
interfaces in this bridge domain, followed by this number of 
bridge_domain_sw_if_details API messages. The cleanup patch changed the 
response to be just one API message of bridge_domain_details which includes an 
array  sw_if_details [n_sw_ifs]  for all BD interface related info. The change 
thus made the API response much simpler and also more feasible for other 
language bindings.  Perhaps it is because the request API has not changed and 
only the responses were, we did not think through what difficulties the change 
may have caused API users without prior warning.

The same patch that was merged also renamed a few API messages to follow naming 
conventions better:
- is_address_reachable - Disabled so deleted cli_request - Renamed to cli 
- vnet_summary_stats_reply - Renamed to vnet_get_summary_stats_reply
- bridge_domain_sw_if_details - Deleted, incorporated in main message 
- l2_fib_table_entry - Renamed to l2_fib_table_details

Regards,
John


-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Luke, Chris
Sent: Tuesday, May 23, 2017 4:40 PM
To: Jon Loeliger ; vpp-dev 
Subject: Re: [vpp-dev] The Case Of the Missing API Definition

It's disappointing that no heads-up was posted to the list. That's the bare 
minimum needed so that downstream consumers are aware of a material change 
before it bites them, especially if they track master.

I'm the last person to suggest we need rules; I hope simple courtesy can 
prevent this in future. :)

Chris.


> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] 
> On Behalf Of Jon Loeliger
> Sent: Tuesday, May 23, 2017 13:20
> To: vpp-dev 
> Subject: [vpp-dev] The Case Of the Missing API Definition
> 
> Folks,
> 
> I was causally walking down Update VPP Master Lane when I was suddenly 
> attacked from behind by a case of the missing API call!
> I read vpp-dev mail daily, and I watch the Gerrit fervently, so I was 
> pretty sure I wouldn't be blind-sided by this sort of Silent Gotcha.
> 
> But there was no mistaking it:  My API call 
> bridge_domain_sw_if_details was gone.  And only two days ago too!  I was 
> shocked.  Horrified, even.
> I knew the next build my code would fail.  There would be no updating 
> to Top-Of-Tree VPP today.
> 
> What would I tell my boss?  *My* code was broken?  Surely you wouldn't 
> expect me to fall on the "I'm sorry.  My code is broken." sword.  My 
> own code!  Surely I could blame someone else?  I mean, what if there 
> were some email from the developers?  A little heads-up that the API 
> was on The Out and would soon go the way of Sonny Bono.  But no, no, 
> there wasn't even a hint.
> 
> I was going to have to admit I failed to see this coming in the Gerrit 
> reviews.
> 
> And now, without even lunch, I would have to deduce what data used to 
> be in that API call, and how it was cached in my VPP interface 
> library, and yes, I'd have to scurry to find where that data was located now.
> 
> But how?  How could this be?  I lamented still.  I just knew last time 
> *I* wanted an API interface change, I spent a week discussing it on 
> the list, and, after deliberation a-plenty, a new API was needed, and 
> then later, in fact after a complete release cycle, we could begin to 
> discuss how the old API call might be deprecated and finally removed.  
> I longed for the day that we would finally make progress, content in 
> the knowledge that we had not, in fact, blind-sided anyone with our API 
> deprecation plan.
> 
> But those days are behind us now, and the future comes at us plenty fast.
> Commits are committed, and progress is progressed.  My scars are 
> healing, and after all this water under and through the bridge, I have 
> learned now to just laugh at these situations.
> 
> Ah, to be young again, and not have wasted my youth on backward 
> compatibility and cheap Scotch.
> 
> jdl
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Ed Warnicke via RT

I got that part.  My point is that it looks like the first DNS for the SOA
is pointing to the DNS in your Portland DC.

Is this the old OSLab DC that is having the power issues?  Or the one we
are considering using for cross project stuff?

Ed

On Tue, May 23, 2017 at 8:27 AM, Andrew Grimberg via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> On Tue May 23 11:03:18 2017, hagbard wrote:
> > OK... why is it listed first in the public SOA then?
> >
> > Ed
>
> Ed,
>
> I think you're missing what is happening here.
>
> Our _internal_ DNS is run out of Portland. The _external_ DNS for FD.io is
> run out of a third party DNS provider.
>
> The cause of the intermittent 500 errors that Gerrit was getting is
> because of connectivity issues affecting Portland itself, apparently
> there's a massive power outage and our DC has been on generators since
> yesterday but that doesn't mean the power problems aren't causing issues
> for the DC nail-ups themselves. The connectivity issues have been causing
> Gerrit to not be able to find the backend database server when it's
> re-opening a connection. As such we've forcibly added the IP resolution to
> the hosts file, which is something we don't normally do.
>
> -Andy-
>
> --
> Andrew Grimberg
> The Linux Foundation
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Ed Warnicke

I got that part.  My point is that it looks like the first DNS for the SOA
is pointing to the DNS in your Portland DC.

Is this the old OSLab DC that is having the power issues?  Or the one we
are considering using for cross project stuff?

Ed

On Tue, May 23, 2017 at 8:27 AM, Andrew Grimberg via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> On Tue May 23 11:03:18 2017, hagbard wrote:
> > OK... why is it listed first in the public SOA then?
> >
> > Ed
>
> Ed,
>
> I think you're missing what is happening here.
>
> Our _internal_ DNS is run out of Portland. The _external_ DNS for FD.io is
> run out of a third party DNS provider.
>
> The cause of the intermittent 500 errors that Gerrit was getting is
> because of connectivity issues affecting Portland itself, apparently
> there's a massive power outage and our DC has been on generators since
> yesterday but that doesn't mean the power problems aren't causing issues
> for the DC nail-ups themselves. The connectivity issues have been causing
> Gerrit to not be able to find the backend database server when it's
> re-opening a connection. As such we've forcibly added the IP resolution to
> the hosts file, which is something we don't normally do.
>
> -Andy-
>
> --
> Andrew Grimberg
> The Linux Foundation
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP now has basic tab completion

2017-05-23 Thread Dave Barach (dbarach)

+1, nice work!

Thanks... Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Luke, Chris
Sent: Tuesday, May 23, 2017 3:00 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP now has basic tab completion

Thanks to the work of Yoann we now have some tab-completion goodness in the 
debug CLI! I know it has been a long-desired feature for many people here.

It works pretty much as you'd expect with the obvious caveat it can only 
complete for things registered with the CLI parser; where commands implement 
their own unformat() parsing for parameters we have no hope of completing on, 
or after, those.

Enjoy! Feedback and enchancements welcome, of course. :)

Chris.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] The Case Of the Missing API Definition

2017-05-23 Thread Luke, Chris

It's disappointing that no heads-up was posted to the list. That's the bare 
minimum needed so that downstream consumers are aware of a material change 
before it bites them, especially if they track master.

I'm the last person to suggest we need rules; I hope simple courtesy can 
prevent this in future. :)

Chris.


> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Jon Loeliger
> Sent: Tuesday, May 23, 2017 13:20
> To: vpp-dev 
> Subject: [vpp-dev] The Case Of the Missing API Definition
> 
> Folks,
> 
> I was causally walking down Update VPP Master Lane when I was suddenly
> attacked from behind by a case of the missing API call!
> I read vpp-dev mail daily, and I watch the Gerrit fervently, so I was pretty
> sure I wouldn't be blind-sided by this sort of Silent Gotcha.
> 
> But there was no mistaking it:  My API call bridge_domain_sw_if_details was
> gone.  And only two days ago too!  I was shocked.  Horrified, even.
> I knew the next build my code would fail.  There would be no updating to
> Top-Of-Tree VPP today.
> 
> What would I tell my boss?  *My* code was broken?  Surely you wouldn't
> expect me to fall on the "I'm sorry.  My code is broken." sword.  My own
> code!  Surely I could blame someone else?  I mean, what if there were some
> email from the developers?  A little heads-up that the API was on The Out
> and would soon go the way of Sonny Bono.  But no, no, there wasn't even a
> hint.
> 
> I was going to have to admit I failed to see this coming in the Gerrit 
> reviews.
> 
> And now, without even lunch, I would have to deduce what data used to be
> in that API call, and how it was cached in my VPP interface library, and yes, 
> I'd
> have to scurry to find where that data was located now.
> 
> But how?  How could this be?  I lamented still.  I just knew last time *I*
> wanted an API interface change, I spent a week discussing it on the list, and,
> after deliberation a-plenty, a new API was needed, and then later, in fact
> after a complete release cycle, we could begin to discuss how the old API call
> might be deprecated and finally removed.  I longed for the day that we
> would finally make progress, content in the knowledge that we had not, in
> fact, blind-sided anyone with our API deprecation plan.
> 
> But those days are behind us now, and the future comes at us plenty fast.
> Commits are committed, and progress is progressed.  My scars are healing,
> and after all this water under and through the bridge, I have learned now to
> just laugh at these situations.
> 
> Ah, to be young again, and not have wasted my youth on backward
> compatibility and cheap Scotch.
> 
> jdl
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP now has basic tab completion

2017-05-23 Thread Florin Coras

Awesome!

Florin

> On May 23, 2017, at 12:00 PM, Luke, Chris  wrote:
> 
> Thanks to the work of Yoann we now have some tab-completion goodness in the 
> debug CLI! I know it has been a long-desired feature for many people here.
>  
> It works pretty much as you’d expect with the obvious caveat it can only 
> complete for things registered with the CLI parser; where commands implement 
> their own unformat() parsing for parameters we have no hope of completing on, 
> or after, those.
>  
> Enjoy! Feedback and enchancements welcome, of course. :)
>  
> Chris.
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP now has basic tab completion

2017-05-23 Thread Ed Warnicke

Tears.  Tears of joy!

Ed

On Tue, May 23, 2017 at 12:00 PM, Luke, Chris 
wrote:

> Thanks to the work of Yoann we now have some tab-completion goodness in
> the debug CLI! I know it has been a long-desired feature for many people
> here.
>
>
>
> It works pretty much as you’d expect with the obvious caveat it can only
> complete for things registered with the CLI parser; where commands
> implement their own unformat() parsing for parameters we have no hope of
> completing on, or after, those.
>
>
>
> Enjoy! Feedback and enchancements welcome, of course. :)
>
>
>
> Chris.
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP now has basic tab completion

2017-05-23 Thread Luke, Chris

Thanks to the work of Yoann we now have some tab-completion goodness in the 
debug CLI! I know it has been a long-desired feature for many people here.

It works pretty much as you'd expect with the obvious caveat it can only 
complete for things registered with the CLI parser; where commands implement 
their own unformat() parsing for parameters we have no hope of completing on, 
or after, those.

Enjoy! Feedback and enchancements welcome, of course. :)

Chris.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] shadow build system change adding test-debug job

2017-05-23 Thread Ed Kern (ejk)

No problem.

If anyone is curious in rubbernecking the accident that is the current test-all 
(at least for my build system)
adding a comment of
testall
SHOULD trigger and fire it off on my end.
make it all pass and you win a beer (or beverage of your choice)

Ed



On May 23, 2017, at 11:34 AM, Dave Wallace 
> wrote:

Ed,

Thanks for adding this to the shadow build system.  Real data on the cost and 
effectiveness of this will be most useful.

-daw-

On 5/23/2017 1:30 PM, Ed Kern (ejk) wrote:

In the vpp-dev call a couple hours ago there was a discussion of running 
test-debug on a regular/default? basis.
As a trial I’ve added a new job to the shadow build system:

vpp-test-debug-master-ubuntu1604

Will do a make test-debug,  as part of verify set, as an ADDITIONAL job.


I gave a couple passes with test-all but can’t ever get a clean run with 
test-all (errors in test_bfd and test_ip6 ).
I don’t think this is unusual or unexpected.  Ill leave it to someone else to 
say that ‘all’ throwing failures is a good thing.
I’m happy to add another job for/with test-all if someone wants to actually 
debug those errors.

flames, comments,concerns welcome..

Ed

PS Please note/remember that all these tests are non-voting regardless of 
success or failure.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] syslog in snat

2017-05-23 Thread Matt Paska

Is there further info/docs on using syslog for snat on the wiki? I searched
through but couldn't find anything.

Thanks.

On Sat, May 13, 2017 at 10:32 PM, Jim Thompson  wrote:

>
> On May 13, 2017, at 11:58 PM, Andrew Taylor 
> wrote:
>
> Hi,
>
> Could you please explain what is "Syslog based SNAT login" in Release
> Plan 17.07
>
>
> Added here, so you could ask
> https://wiki.fd.io/index.php?title=Projects%2Fvpp%
> 2FRelease_Plans%2FRelease_Plan_17.07
> 
> iff=5072=5071
> 
>
>
> Is it an alternative option for logging session like IPFIX ?
>
>
> I suspect this was intended to be “syslog-based SNAT logging”, and that
> only the final ‘g’ is missing.
>
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] shadow build system change adding test-debug job

2017-05-23 Thread Ed Kern (ejk)


In the vpp-dev call a couple hours ago there was a discussion of running 
test-debug on a regular/default? basis.
As a trial I’ve added a new job to the shadow build system:

vpp-test-debug-master-ubuntu1604

Will do a make test-debug,  as part of verify set, as an ADDITIONAL job.


I gave a couple passes with test-all but can’t ever get a clean run with 
test-all (errors in test_bfd and test_ip6 ).
I don’t think this is unusual or unexpected.  Ill leave it to someone else to 
say that ‘all’ throwing failures is a good thing.
I’m happy to add another job for/with test-all if someone wants to actually 
debug those errors.

flames, comments,concerns welcome..

Ed

PS Please note/remember that all these tests are non-voting regardless of 
success or failure.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Damjan Marion (damarion)


Can you try following patch without manual bind:

https://gerrit.fd.io/r/#/c/6846

Thanks,

Damjan


> On 23 May 2017, at 15:53, Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES 
> at Cisco)  wrote:
> 
> Hi Dave,
> 
> The manual binding helped. I used uio_pci_generic and now VPP finally sees 
> them. Thanks.
> 
> Michal
> 
> -Original Message-
> From: Dave Barach (dbarach) 
> Sent: Tuesday, May 23, 2017 3:39 PM
> To: Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) 
> ; Marco Varlese ; Kinsella, Ray 
> ; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
> master
> 
> Please attempt to bind the VIC device(s) manually - to uio_pci_generic - 
> using dpdk-devbind. 
> 
> Until / unless that works, there isn't a chance that vpp will drive the 
> devices. You may have better luck with the igb_uio kernel module, or not... 
> 
> Thanks… Dave
> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)
> Sent: Tuesday, May 23, 2017 9:13 AM
> To: Marco Varlese ; Kinsella, Ray 
> ; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
> master
> 
> Hi,
> 
> I meant that they are in DOWN state in "ip link list":
> [root@overcloud-novacompute-1 ~]# ip link list
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
> DEFAULT qlen 1
>link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: enp6s0:  mtu 1500 qdisc mq state UP mode 
> DEFAULT qlen 1000
>link/ether 00:25:b5:00:01:50 brd ff:ff:ff:ff:ff:ff
> 3: enp7s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
> qlen 1000
>link/ether 00:25:b5:00:01:4f brd ff:ff:ff:ff:ff:ff
> 4: enp8s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
> qlen 1000
>link/ether 00:25:b5:00:01:4e brd ff:ff:ff:ff:ff:ff
> 
> I also tried to unbind them like you suggested. then the status of 
> dpdk-nicbind is:
> [root@overcloud-novacompute-1 tools]# dpdk_nic_bind --status
> 
> Network devices using DPDK-compatible driver 
> 
> 
> 
> Network devices using kernel driver
> ===
> :06:00.0 'VIC Ethernet NIC' if=enp6s0 drv=enic 
> unused=vfio-pci,uio_pci_generic *Active*
> :09:00.0 'VIC Ethernet NIC' if=enp9s0 drv=enic 
> unused=vfio-pci,uio_pci_generic *Active*
> :0a:00.0 'VIC Ethernet NIC' if=enp10s0 drv=enic 
> unused=vfio-pci,uio_pci_generic *Active*
> :0f:00.0 'VIC Ethernet NIC' if=enp15s0 drv=enic 
> unused=vfio-pci,uio_pci_generic
> :10:00.0 'VIC Ethernet NIC' if=enp16s0 drv=enic 
> unused=vfio-pci,uio_pci_generic
> :11:00.0 'VIC Ethernet NIC' if=enp17s0 drv=enic 
> unused=vfio-pci,uio_pci_generic
> :12:00.0 'VIC Ethernet NIC' if=enp18s0 drv=enic 
> unused=vfio-pci,uio_pci_generic
> 
> Other network devices
> =
> :07:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic
> :08:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic
> 
> [root@overcloud-novacompute-1 tools]# vpp unix interactive
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
> (experimetal))
> load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address 
> Translation)
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/acl_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
> /usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
> load_one_plugin:63: Loaded plugin: 
>

Re: [vpp-dev] ACL Match in fa_node.c

2017-05-23 Thread 张攀

Hi Andrew!

-- Original --
From:  "Andrew   Yourtchenko";
Date:  Tue, May 23, 2017 07:56 PM
To:  "张攀"; 
Cc:  "vpp-dev"; 
Subject:  Re: [vpp-dev] ACL Match in fa_node.c

Hi!

On 5/23/17, 张攀  wrote:
> Hi guys,
>
>
> I looked into the source code of vpp/src/plugin/acl/fa_node.c,
> in function full_acl_match_5tuple(), it seems that every ingress packet is
> matching against each ACL rule stored in acl_main->acls in a for-loop
> manner. This seems not fairly effective.

You're absolutely right on both counts. First make it work, then make
it right, then make it fast :-) I have some ideas that I wanted to
experiment with there, would you be interested to help ? ACL matching
is a fairly distinct function operation to not affect much else.

[PAN]: I would be very pleased to help as I am also a addicted person to high 
performance programming :D

>
>
> Besides, I notice that in vpp/src/plugin/acl/acl.c，when you call the
> function acl_hook_l2_input_classify(), you will create a
> vnet_classify_table, but I didn't see any code which adds classify_session
> to it, why?

I had used classify table for storing the sessions in the pre-1704
version of the ACL plugin.

in 1704 as I was adding the L3, I moved to the new data path while
keeping the old one still around, and potentially switchable (not
terribly gracefully, but still).

In the current master the classifier is used merely as a hook to get
into the packet processing within the L2 packet path - that's why you
see no sessions added.

[PAN]: Cool. Correct me if I am wrong: ingress packet will first check against 
if there is matched session existing
in fa_node.c and if not, the packet will check against ACL then to decide 
whether to create a new session or drop.

Is there any 'match then action' alike behavior existing in fa_node?  And a 
long standing mystery question for me: what
does "fa" stand for :p

>
>
> Is there any document/idea could basically explain the relationships between
> acl/fa_node and vnet_classify?

In a gerrit draft that I am working now on, which aims to provide the
multicore support, there is text file with the history and the
description of operation. If you like, I can add you to the reviewers
list so you can have a look at that - just send me your email that you
use in gerrit.

[PAN]: Thank you Andrew, I believe this will help a lot. My email is
 dazhang...@gmail.com

--a

>
>
> Any help will be much appreciated.
>
>
> Best Regards,
>
>
> Pan___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] DPDK Crypto Plugin: rte_cryptodev_enqueue_burst does not return Decrypted packets

2017-05-23 Thread Sergio Gonzalez Monroy


Hi,

So without the change to dpdk.am, does the build completes correctly 
(including both crypto libraries) but you fail to load the plugin?

Are you building a VPP release or from master?

Sergio

On 22/05/2017 05:21, Avinash Gonsalves wrote:


Need help with the  DPDK crypto plugin,


After I moved to the DPDK Crypto plugin, and built it with:

/make vpp_uses_dpdk_cryptodev_sw=yes build/

//
On running VPP faced the following error:

/load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)/

/load_one_plugin:142: 
/vpp/build-root/install-vpp-native/vpp/lib64/vpp_plugins/dpdk_plugin.so: 
undefined symbol: aesni_gcm128_init/


/load_one_plugin:143: Failed to load plugin 'dpdk_plugin.so'/

/Aborted (core dumped)/


I fixed this one by modifying to use a share lib,

--- a/fastpath/vpp/vpp-src/src/plugins/dpdk.am 

+++ b/fastpath/vpp/vpp-src/src/plugins/dpdk.am 

@@ -17,9 +17,10 @@ vppplugins_LTLIBRARIES += dpdk_plugin.la 



 dpdk_plugin_la_LDFLAGS = $(AM_LDFLAGS) 
-Wl,--whole-archive,-l:libdpdk.a,--no-whole-archive


 if WITH_DPDK_CRYPTO_SW

 dpdk_plugin_la_LDFLAGS += 
-Wl,--exclude-libs,libIPSec_MB.a,-l:libIPSec_MB.a


-dpdk_plugin_la_LDFLAGS += 
-Wl,--exclude-libs,libisal_crypto.a,-l:libisal_crypto.a


-endif

+dpdk_plugin_la_LDFLAGS += -Wl,-lm,-ldl,-lisal_crypto

+else

 dpdk_plugin_la_LDFLAGS += -Wl,-lm,-ldl

+endif



After this change, the rte_cryptodev_enqueue_burst, does not return 
decrypted packets.

Any configuration that I'm missing?


This is my system configuration:

/No LSB modules are available./

/Distributor ID:  Ubuntu/

/Description: Ubuntu 16.04.1 LTS/

/Release: 16.04/

/Codename: xenial/

/# uname -a/

/Linux VPP 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux/







___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Andrew Grimberg via RT

On Tue May 23 11:03:18 2017, hagbard wrote:
> OK... why is it listed first in the public SOA then?
> 
> Ed

Ed,

I think you're missing what is happening here.

Our _internal_ DNS is run out of Portland. The _external_ DNS for FD.io is run 
out of a third party DNS provider.

The cause of the intermittent 500 errors that Gerrit was getting is because of 
connectivity issues affecting Portland itself, apparently there's a massive 
power outage and our DC has been on generators since yesterday but that doesn't 
mean the power problems aren't causing issues for the DC nail-ups themselves. 
The connectivity issues have been causing Gerrit to not be able to find the 
backend database server when it's re-opening a connection. As such we've 
forcibly added the IP resolution to the hosts file, which is something we don't 
normally do.

-Andy-

-- 
Andrew Grimberg
The Linux Foundation
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Ed Warnicke

OK... why is it listed first in the public SOA then?

Ed

On Tue, May 23, 2017 at 7:57 AM, Jordan Conway via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> Hi Ed,
> This is internal DNS.
>
> Cheers,
> Jordan
>
> On Tue, May 23, 2017 at 10:47 AM, Ed Warnicke  wrote:
> Jordan,
>
> Why are we still running DNS out of the Portland DC?  I thought we were
> having that handled professionally now?
>
> Ed
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Ed Warnicke via RT

OK... why is it listed first in the public SOA then?

Ed

On Tue, May 23, 2017 at 7:57 AM, Jordan Conway via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> Hi Ed,
> This is internal DNS.
>
> Cheers,
> Jordan
>
> On Tue, May 23, 2017 at 10:47 AM, Ed Warnicke  wrote:
> Jordan,
>
> Why are we still running DNS out of the Portland DC?  I thought we were
> having that handled professionally now?
>
> Ed
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Jordan Conway via RT

Hi Ed,
This is internal DNS.

Cheers,
Jordan

On Tue, May 23, 2017 at 10:47 AM, Ed Warnicke  wrote:
Jordan,

Why are we still running DNS out of the Portland DC?  I thought we were having 
that handled professionally now?

Ed
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] make in debian 8

2017-05-23 Thread Damjan Marion (damarion)


> On 23 May 2017, at 16:25, emma sdi  wrote:
> 
> Dear VPP folks,
> 
> I build vpp in debian 8, with a little changes in makefile.
> Do you want this kind of commits?!

sure, submit to gerrit for review….

Thanks
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] [FD.io Helpdesk #41053] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Jordan Conway via RT

Replied out of band in response to emergency page, adding to RT:

~~~
Hi Dave,
It looks like there might be some intermittent dns resolution issues causing 
problems accessing the backend database.
I've added an /etc/hosts entry for the database server on the gerrit server so 
that dns failures will not cause a gerrit failure while we continue to 
investigate the root cause of the dns issues.

Cheers,
Jordan
~~~

It appears that this has cleared things up for now - it seems that the dns 
resolution issues may be related to ongoing power outages near out PDX 
datacenter that may be affecting network stability.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] make in debian 8

2017-05-23 Thread emma sdi

Dear VPP folks,

I build vpp in debian 8, with a little changes in makefile.
Do you want this kind of commits?!

Regards,
khers
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] FW: [FD.io Helpdesk #41053] AutoReply: sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Dave Barach via RT

Gerrit.fd.io is more or less unusable at the moment. Please take a look.

Thanks… Dave

-Original Message-
From: FD.io Helpdesk via RT [mailto:fdio-helpd...@rt.linuxfoundation.org] 
Sent: Tuesday, May 23, 2017 10:08 AM
To: Dave Barach (dbarach) 
Subject: [FD.io Helpdesk #41053] AutoReply: sporadic gerrit.fd.io html error 
500 "Internal server error"

Greetings,

Your support ticket regarding:
"sporadic gerrit.fd.io html error 500 "Internal server error"", 
has been entered in our ticket tracker.  A summary of your ticket appears below.

If you have any follow-up related to this issue, please reply to this email or 
include:

 [FD.io Helpdesk #41053]

in the subject line of subsequent emails.

Thank you,
Linux Foundation Support Team

-
I've seen this a few times this morning. Please check the logs...

Thanks... Dave

[cid:image001.jpg@01D2D3AC.659624E0]

Thanks... Dave

-- 
You received this message because you are subscribed to the Google Groups 
"Emergency Admin Alert" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emergency+unsubscr...@linuxfoundation.org.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] sporadic gerrit.fd.io html error 500 "Internal server error"

2017-05-23 Thread Dave Barach (dbarach)

I've seen this a few times this morning. Please check the logs...

Thanks... Dave


[cid:image001.jpg@01D2D3AC.659624E0]

Thanks... Dave

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)

Hi Dave,

The manual binding helped. I used uio_pci_generic and now VPP finally sees 
them. Thanks.

Michal

-Original Message-
From: Dave Barach (dbarach) 
Sent: Tuesday, May 23, 2017 3:39 PM
To: Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) 
; Marco Varlese ; Kinsella, Ray 
; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
master

Please attempt to bind the VIC device(s) manually - to uio_pci_generic - using 
dpdk-devbind. 

Until / unless that works, there isn't a chance that vpp will drive the 
devices. You may have better luck with the igb_uio kernel module, or not... 

Thanks… Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, May 23, 2017 9:13 AM
To: Marco Varlese ; Kinsella, Ray 
; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
master

Hi,

I meant that they are in DOWN state in "ip link list":
[root@overcloud-novacompute-1 ~]# ip link list
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0:  mtu 1500 qdisc mq state UP mode 
DEFAULT qlen 1000
link/ether 00:25:b5:00:01:50 brd ff:ff:ff:ff:ff:ff
3: enp7s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4f brd ff:ff:ff:ff:ff:ff
4: enp8s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4e brd ff:ff:ff:ff:ff:ff

I also tried to unbind them like you suggested. then the status of dpdk-nicbind 
is:
[root@overcloud-novacompute-1 tools]# dpdk_nic_bind --status

Network devices using DPDK-compatible driver 



Network devices using kernel driver
===
:06:00.0 'VIC Ethernet NIC' if=enp6s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:09:00.0 'VIC Ethernet NIC' if=enp9s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0a:00.0 'VIC Ethernet NIC' if=enp10s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0f:00.0 'VIC Ethernet NIC' if=enp15s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:10:00.0 'VIC Ethernet NIC' if=enp16s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:11:00.0 'VIC Ethernet NIC' if=enp17s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:12:00.0 'VIC Ethernet NIC' if=enp18s0 drv=enic 
unused=vfio-pci,uio_pci_generic

Other network devices
=
:07:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic
:08:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic

[root@overcloud-novacompute-1 tools]# vpp unix interactive
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
load_one_plugin:63: Loaded plugin:

Re: [vpp-dev] Question regarding pool_get/pool_put thread safety

2017-05-23 Thread Luke, Chris

It is not thread safe; it’s up to the caller to be thread safe. Typically each 
thread works on its own memory and objects to avoid cross-thread locking or 
cross-socket cache invalidation.

Most volatile objects are typically modified by the API or CLI and there’s a 
main thread that hosts these entry points and In effect this serializes 
accesses so that locking/synchronization is much less necessary.

Where it’s absolutely necessary we use spinlocks to synchronize such things but 
try really hard not to.

Chris.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of ???
Sent: Monday, May 22, 2017 22:38
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Question regarding pool_get/pool_put thread safety

Hi folks,

There is a pool_get and pool_put macro based on vec structure, quite a few code 
rely on that, however, I have a question regarding about the thread safety of 
these two APIs, I do not found any comments for them.

Since pool_get may resize the vec, is there any issue if another worker thread 
trying to use pool_put which may refer to the old underlying vec?

Or there is some implicit coding convention to use the two APIs?

Thanks a lot.


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Does VPP support vlan 0?

2017-05-23 Thread Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco)

Hi vpp-devs,

I'm hitting an issue when VLAN ID is 0:
03:20:01:825468: tapcli-rx
tap-0
03:20:01:825472: ethernet-input
IP4: 00:25:b5:00:01:4a -> 01:00:5e:00:00:12 802.1q vlan 0
03:20:01:825473: error-drop
ethernet-input: unknown vlan

As I understand it, the device should treat packets with VLAN 0 as if it didn't 
have an ID:
The null VLAN ID. Indicates that the tag header contains only priority
information; no VLAN identifier is present in the frame.

I'm trying this with 1704. Does VPP support this? Is there a workaround, like 
stripping the 802.1q header for tap ports?

Thanks,
Juraj
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Dave Barach (dbarach)

Please attempt to bind the VIC device(s) manually - to uio_pci_generic - using 
dpdk-devbind. 

Until / unless that works, there isn't a chance that vpp will drive the 
devices. You may have better luck with the igb_uio kernel module, or not... 

Thanks… Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)
Sent: Tuesday, May 23, 2017 9:13 AM
To: Marco Varlese ; Kinsella, Ray 
; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
master

Hi,

I meant that they are in DOWN state in "ip link list":
[root@overcloud-novacompute-1 ~]# ip link list
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0:  mtu 1500 qdisc mq state UP mode 
DEFAULT qlen 1000
link/ether 00:25:b5:00:01:50 brd ff:ff:ff:ff:ff:ff
3: enp7s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4f brd ff:ff:ff:ff:ff:ff
4: enp8s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4e brd ff:ff:ff:ff:ff:ff

I also tried to unbind them like you suggested. then the status of dpdk-nicbind 
is:
[root@overcloud-novacompute-1 tools]# dpdk_nic_bind --status

Network devices using DPDK-compatible driver



Network devices using kernel driver
===
:06:00.0 'VIC Ethernet NIC' if=enp6s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:09:00.0 'VIC Ethernet NIC' if=enp9s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0a:00.0 'VIC Ethernet NIC' if=enp10s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0f:00.0 'VIC Ethernet NIC' if=enp15s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:10:00.0 'VIC Ethernet NIC' if=enp16s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:11:00.0 'VIC Ethernet NIC' if=enp17s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:12:00.0 'VIC Ethernet NIC' if=enp18s0 drv=enic 
unused=vfio-pci,uio_pci_generic

Other network devices
=
:07:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic
:08:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic

[root@overcloud-novacompute-1 tools]# vpp unix interactive
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
EAL: No free hugepages reported in hugepages-1048576kB
EAL: VFIO support initialized
DPDK physical memory layout:
Segment 0: phys:0x1840, len:247463936, virt:0x7faebc00, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x31c0, len:20971520, virt:0x7fae9560, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x2d4480, len:2097152, virt:0x7fac5640, socket_id:1, 
hugepage_sz:2097152,

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)

Hi,

I meant that they are in DOWN state in "ip link list":
[root@overcloud-novacompute-1 ~]# ip link list
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0:  mtu 1500 qdisc mq state UP mode 
DEFAULT qlen 1000
link/ether 00:25:b5:00:01:50 brd ff:ff:ff:ff:ff:ff
3: enp7s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4f brd ff:ff:ff:ff:ff:ff
4: enp8s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
qlen 1000
link/ether 00:25:b5:00:01:4e brd ff:ff:ff:ff:ff:ff

I also tried to unbind them like you suggested. then the status of dpdk-nicbind 
is:
[root@overcloud-novacompute-1 tools]# dpdk_nic_bind --status

Network devices using DPDK-compatible driver



Network devices using kernel driver
===
:06:00.0 'VIC Ethernet NIC' if=enp6s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:09:00.0 'VIC Ethernet NIC' if=enp9s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0a:00.0 'VIC Ethernet NIC' if=enp10s0 drv=enic 
unused=vfio-pci,uio_pci_generic *Active*
:0f:00.0 'VIC Ethernet NIC' if=enp15s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:10:00.0 'VIC Ethernet NIC' if=enp16s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:11:00.0 'VIC Ethernet NIC' if=enp17s0 drv=enic 
unused=vfio-pci,uio_pci_generic
:12:00.0 'VIC Ethernet NIC' if=enp18s0 drv=enic 
unused=vfio-pci,uio_pci_generic

Other network devices
=
:07:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic
:08:00.0 'VIC Ethernet NIC' unused=enic,vfio-pci,uio_pci_generic

[root@overcloud-novacompute-1 tools]# vpp unix interactive
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
EAL: No free hugepages reported in hugepages-1048576kB
EAL: VFIO support initialized
DPDK physical memory layout:
Segment 0: phys:0x1840, len:247463936, virt:0x7faebc00, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x31c0, len:20971520, virt:0x7fae9560, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x2d4480, len:2097152, virt:0x7fac5640, socket_id:1, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: phys:0x2d44c0, len:266338304, virt:0x7faa26a0, socket_id:1, 
hugepage_sz:2097152, nchannel:0, nrank:0
0: dpdk_ipsec_process:239: not enough Cryptodevs, default to OpenSSL IPsec
0: dpdk_lib_init:182: DPDK drivers found no ports...
0: svm_client_scan_this_region_nolock:1140: /vpe-api: cleanup ghost pid 6623
0: svm_client_scan_this_region_nolock:1140: /global_vm: cleanup ghost pid 6623
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# sh int
  Name   Idx   State  Counter

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Marco Varlese

You say the ports are "down"... not sure how to interpret that but it might mean
that are still being binded to the kernel drivers.

Did you try and see if those ports are still binded with the Linux kernel
drivers? What is "dpdk-devbind.py --status" reporting?

What driver are you using in startup.conf to be used with DPDK? (vfio-pci? uio-
pci-generic? igb_uio?). Can you make sure the respective driver is loaded on the
system?

You can unbind the ports from the kernel drivers via
dpdk-devbind.py --unbind :82:00.0 (where :82:00.0 is the PCI address
representing your port on your system)


- Marco

On Tue, 2017-05-23 at 12:19 +, Michal Cmarada -X (mcmarada - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Yes it shoud be enabled because I see "DPDK drivers found no ports..." in
> output from "vpp unix interactive" command:
> 
> [root@overcloud-novacompute-1 ~]# vpp unix interactive
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit
> (DPDK))
> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address
> Translation)
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/acl_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/lb_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/snat_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
> EAL: No free hugepages reported in hugepages-1048576kB
> EAL: VFIO support initialized
> DPDK physical memory layout:
> Segment 0: phys:0x1840, len:247463936, virt:0x7f9d81a0, socket_id:0,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 1: phys:0x31c0, len:20971520, virt:0x7f9d5b00, socket_id:0,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 2: phys:0x2d4480, len:2097152, virt:0x7f9b1be0, socket_id:1,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 3: phys:0x2d44c0, len:266338304, virt:0x7f98ec40, socket_id:1,
> hugepage_sz:2097152, nchannel:0, nrank:0
> 0: dpdk_ipsec_process:239: not enough Cryptodevs, default to OpenSSL IPsec
> 0: dpdk_lib_init:182: DPDK drivers found no ports...
> 0: svm_client_scan_this_region_nolock:1140: /vpe-api: cleanup ghost pid 5540
> 0: svm_client_scan_this_region_nolock:1140: /global_vm: cleanup ghost pid 5540
> _____   _  ___
>  __/ __/ _ \  (_)__| | / / _ \/ _ \
>  _/ _// // / / / _ \   | |/ / ___/ ___/
>  /_/ /(_)_/\___/   |___/_/  /_/
> 
> vpp# sh int
>   Name   Idx   State  Counter  Cou
> nt
> local00down
> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Kinsella, Ray
> Sent: Tuesday, May 23, 2017 2:16 PM
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707
> master
> 
> Is the dpdk plugin enabled?
> 
> Ray K
> 
> On 23/05/2017 13:01, Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at
> Cisco) wrote:
> > 
> > Hi VPP devs,
> > 
> > 
> > 
> > I tried to update VPP to master version from stable 1704 on Centos. In
> > 1704 everything was working. Now in 1707 master VPP does not pick the 
> > physical interfaces. I tried to change the drivers and I whitelisted 
> > the interfaces in startup.conf for vpp. All the interfaces are down so 
> > VPP should pick them. But nothing

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)

Yes it shoud be enabled because I see "DPDK drivers found no ports..." in 
output from "vpp unix interactive" command:

[root@overcloud-novacompute-1 ~]# vpp unix interactive
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment 
on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface 
(experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
EAL: No free hugepages reported in hugepages-1048576kB
EAL: VFIO support initialized
DPDK physical memory layout:
Segment 0: phys:0x1840, len:247463936, virt:0x7f9d81a0, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x31c0, len:20971520, virt:0x7f9d5b00, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x2d4480, len:2097152, virt:0x7f9b1be0, socket_id:1, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: phys:0x2d44c0, len:266338304, virt:0x7f98ec40, socket_id:1, 
hugepage_sz:2097152, nchannel:0, nrank:0
0: dpdk_ipsec_process:239: not enough Cryptodevs, default to OpenSSL IPsec
0: dpdk_lib_init:182: DPDK drivers found no ports...
0: svm_client_scan_this_region_nolock:1140: /vpe-api: cleanup ghost pid 5540
0: svm_client_scan_this_region_nolock:1140: /global_vm: cleanup ghost pid 5540
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# sh int
  Name   Idx   State  Counter  Count
local00down

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Kinsella, Ray
Sent: Tuesday, May 23, 2017 2:16 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 
master

Is the dpdk plugin enabled?

Ray K

On 23/05/2017 13:01, Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at 
Cisco) wrote:
> Hi VPP devs,
>
>
>
> I tried to update VPP to master version from stable 1704 on Centos. In
> 1704 everything was working. Now in 1707 master VPP does not pick the 
> physical interfaces. I tried to change the drivers and I whitelisted 
> the interfaces in startup.conf for vpp. All the interfaces are down so 
> VPP should pick them. But nothing works. I tried to update dpdk to the 
> version that was provided on vpp repo but it didn`t help. Can you help 
> me with this issue?
>
>
>
> Here are some details that may help:
>
> OS: centos-release-7-3.1611.el7.centos.x86_64
>
>
>
> Installed Packages
>
> Name: vpp
>
> Arch: x86_64
>
> Version : 17.07
>
> Release : rc0~274_gbb292f4~b2376
>
> Size: 1.7 M
>
> Repo: installed
>
> From repo   : fdio-master
>
> Summary : Vector Packet Processing
>
> License : MIT
>
> Description : This package provides VPP executables: vpp, 
> vpp_api_test, vpp_json_test
>
> : vpp - the vector packet engine
>
> : vpp_api_test - vector packet engine API test tool
>
> : vpp_json_test - vector packet engine JSON test tool
>
>
>
> Installed Packages
>
> Name: dpdk
>
> Arch: x86_64
>
> Version :

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Kinsella, Ray


Is the dpdk plugin enabled?

Ray K

On 23/05/2017 13:01, Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES 
at Cisco) wrote:

Hi VPP devs,



I tried to update VPP to master version from stable 1704 on Centos. In
1704 everything was working. Now in 1707 master VPP does not pick the
physical interfaces. I tried to change the drivers and I whitelisted the
interfaces in startup.conf for vpp. All the interfaces are down so VPP
should pick them. But nothing works. I tried to update dpdk to the
version that was provided on vpp repo but it didn`t help. Can you help
me with this issue?



Here are some details that may help:

OS: centos-release-7-3.1611.el7.centos.x86_64



Installed Packages

Name: vpp

Arch: x86_64

Version : 17.07

Release : rc0~274_gbb292f4~b2376

Size: 1.7 M

Repo: installed

From repo   : fdio-master

Summary : Vector Packet Processing

License : MIT

Description : This package provides VPP executables: vpp, vpp_api_test,
vpp_json_test

: vpp - the vector packet engine

: vpp_api_test - vector packet engine API test tool

: vpp_json_test - vector packet engine JSON test tool



Installed Packages

Name: dpdk

Arch: x86_64

Version : 16.11

Release : 5.el7.centos

Size: 3.5 M

Repo: installed

From repo   : fdio-master

Summary : Set of libraries and drivers for fast packet processing

URL : http://dpdk.org

License : BSD and LGPLv2 and GPLv2

Description : The Data Plane Development Kit is a set of libraries and
drivers for

: fast packet processing in the user space.



vpp# sh pci

Address  Sock VID:PID Link Speed   Driver  Product
NameVital Product Data

:06:00.0   0  1137:0043   8.0 GT/s x16 enic

:07:00.0   0  1137:0043   8.0 GT/s x16 enic

:08:00.0   0  1137:0043   8.0 GT/s x16 enic

:09:00.0   0  1137:0043   8.0 GT/s x16 enic

:10:00.0   0  1137:0043   8.0 GT/s x16 enic

:11:00.0   0  1137:0043   8.0 GT/s x16 enic

:12:00.0   0  1137:0043   8.0 GT/s x16 enic

:0a:00.0   0  1137:0043   8.0 GT/s x16 enic

:0f:00.0   0  1137:0043   8.0 GT/s x16 enic



Thanks

Michal



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

2017-05-23 Thread Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco)

Hi VPP devs,

I tried to update VPP to master version from stable 1704 on Centos. In 1704 
everything was working. Now in 1707 master VPP does not pick the physical 
interfaces. I tried to change the drivers and I whitelisted the interfaces in 
startup.conf for vpp. All the interfaces are down so VPP should pick them. But 
nothing works. I tried to update dpdk to the version that was provided on vpp 
repo but it didn`t help. Can you help me with this issue?

Here are some details that may help:

OS: centos-release-7-3.1611.el7.centos.x86_64

Installed Packages
Name: vpp
Arch: x86_64
Version : 17.07
Release : rc0~274_gbb292f4~b2376
Size: 1.7 M
Repo: installed
>From repo   : fdio-master
Summary : Vector Packet Processing
License : MIT
Description : This package provides VPP executables: vpp, vpp_api_test, 
vpp_json_test
: vpp - the vector packet engine
: vpp_api_test - vector packet engine API test tool
: vpp_json_test - vector packet engine JSON test tool

Installed Packages
Name: dpdk
Arch: x86_64
Version : 16.11
Release : 5.el7.centos
Size: 3.5 M
Repo: installed
>From repo   : fdio-master
Summary : Set of libraries and drivers for fast packet processing
URL : http://dpdk.org
License : BSD and LGPLv2 and GPLv2
Description : The Data Plane Development Kit is a set of libraries and drivers 
for
: fast packet processing in the user space.

vpp# sh pci
Address  Sock VID:PID Link Speed   Driver  Product Name 
   Vital Product Data
:06:00.0   0  1137:0043   8.0 GT/s x16 enic
:07:00.0   0  1137:0043   8.0 GT/s x16 enic
:08:00.0   0  1137:0043   8.0 GT/s x16 enic
:09:00.0   0  1137:0043   8.0 GT/s x16 enic
:10:00.0   0  1137:0043   8.0 GT/s x16 enic
:11:00.0   0  1137:0043   8.0 GT/s x16 enic
:12:00.0   0  1137:0043   8.0 GT/s x16 enic
:0a:00.0   0  1137:0043   8.0 GT/s x16 enic
:0f:00.0   0  1137:0043   8.0 GT/s x16 enic

Thanks
Michal
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] ACL Match in fa_node.c

2017-05-23 Thread 张攀

Hi guys,


I looked into the source code of vpp/src/plugin/acl/fa_node.c,
in function full_acl_match_5tuple(), it seems that every ingress packet is 
matching against each ACL rule stored in acl_main->acls in a for-loop manner. 
This seems not fairly effective.


Besides, I notice that in vpp/src/plugin/acl/acl.c，when you call the function 
acl_hook_l2_input_classify(), you will create a vnet_classify_table, but I 
didn't see any code which adds classify_session to it, why?


Is there any document/idea could basically explain the relationships between 
acl/fa_node and vnet_classify? 


Any help will be much appreciated.


Best Regards,


Pan___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Assert appears when configuring MPLS tunnel

2017-05-23 Thread 薛欣颖

Hi neale,

Thank you very much.

Thanks,
Xyxue

From: Neale Ranns (nranns)
Date: 2017-05-23 19:13
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] Assert appears when configuring MPLS tunnel
Hi Xyxue,

https://gerrit.fd.io/r/#/c/6837/

regards,
neale

From:  on behalf of "Neale Ranns (nranns)" 

Date: Tuesday, 23 May 2017 at 08:42
To: 薛欣颖 , vpp-dev 
Subject: Re: [vpp-dev] Assert appears when configuring MPLS tunnel

Hi Xyxue,

Nothing wrong with that config. But there is a bug in VPP. I’ll fix that ASAP.

Thanks,
neale

From:  on behalf of 薛欣颖 
Date: Tuesday, 23 May 2017 at 07:52
To: vpp-dev 
Subject: [vpp-dev] Assert appears when configuring MPLS tunnel

Hi guys,

Why the assert appear on version 17.07, is there anything wrong with my 
configuration?
DBGvpp# mpls local-label add eos 33 ip4-lookup-in-table 1
DBGvpp# mpls local-label add non-eos 34  mpls-lookup-in-table 0
DBGvpp# mpls tunnel add via 2.1.1.1 host-eth1 out-label 1023
DBGvpp# set int state mpls-tunnel0 up
DBGvpp# ip route add 192.168.1.0/24 via mpls-tunnel0 out-label 1024
0: /home/vpp_1707/vpp/build-data/../src/vnet/dpo/dpo.c:329 (dpo_get_next_node) 
assertion `NULL != dpo_nodes[parent_type]' fails
Aborted
/ # Connection closed by foreign host.

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [multi-thread] Is it safe to pool_get and pool_put in different thread?

2017-05-23 Thread Dave Barach (dbarach)

Pools are not inherently thread-safe.

Coding techniques: allocating a pool per thread [preferred], guarding pool 
accesses with spinlocks or pthread mutex / condvar pairs, preallocate and 
barrier sync [tricky].

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of ???
Sent: Monday, May 22, 2017 10:36 PM
To: vpp-dev 
Subject: [vpp-dev] [multi-thread] Is it safe to pool_get and pool_put in 
different thread?

I am try to add some test code in vpp.
It works well in single-thread mode, but I am confused when I want to use it in 
a multi-thread with worker threads mode.
I will use pool_get in a work thread(different work will use different pool), 
and pool_put in the main thread.

When use pool_get to get a buffer, it may cause a memory resize.
If at the same time the main thread use pool_put to relese the buffer, is it 
possible the main thread is operatoring in the old pool memory.
or in a extreme situation, the old memory has been alloced to other, the 
pool_put will change other's memory?

For the pool or vec in vpp, is it just safe when we get and put in the same 
threadindex?

Thanks
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Assert appears when configuring MPLS tunnel

2017-05-23 Thread Neale Ranns (nranns)

Hi Xyxue,

https://gerrit.fd.io/r/#/c/6837/

regards,
neale

From:  on behalf of "Neale Ranns (nranns)" 

Date: Tuesday, 23 May 2017 at 08:42
To: 薛欣颖 , vpp-dev 
Subject: Re: [vpp-dev] Assert appears when configuring MPLS tunnel

Hi Xyxue,

Nothing wrong with that config. But there is a bug in VPP. I’ll fix that ASAP.

Thanks,
neale

From:  on behalf of 薛欣颖 
Date: Tuesday, 23 May 2017 at 07:52
To: vpp-dev 
Subject: [vpp-dev] Assert appears when configuring MPLS tunnel

Hi guys,

Why the assert appear on version 17.07, is there anything wrong with my 
configuration?
DBGvpp# mpls local-label add eos 33 ip4-lookup-in-table 1
DBGvpp# mpls local-label add non-eos 34  mpls-lookup-in-table 0
DBGvpp# mpls tunnel add via 2.1.1.1 host-eth1 out-label 1023
DBGvpp# set int state mpls-tunnel0 up
DBGvpp# ip route add 192.168.1.0/24 via mpls-tunnel0 out-label 1024
0: /home/vpp_1707/vpp/build-data/../src/vnet/dpo/dpo.c:329 (dpo_get_next_node) 
assertion `NULL != dpo_nodes[parent_type]' fails
Aborted
/ # Connection closed by foreign host.

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ALG

2017-05-23 Thread otroan

Hi Ewan,

> Is there any plan to surpport ALG?

I am quite the non-believer with regards to ALGs.
But you can always make a proposal. What ALGs do you need and why?

Best regards,
Ole


signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS LABEL

2017-05-23 Thread 薛欣颖

Hi neale,

Got it. Thank you very much!

Thanks,
Xyxue

From: Neale Ranns (nranns)
Date: 2017-05-23 18:21
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] MPLS LABEL
Hi Xyxue,

Yes, that’s correct. Note the ip4-lookup-in-table-1 implies a VRF lookup.

Regards,
neale

From: 薛欣颖 
Date: Tuesday, 23 May 2017 at 10:15
To: "Neale Ranns (nranns)" , vpp-dev 
Subject: Re: Re: [vpp-dev] MPLS LABEL

Hi neale,

Thank you very much for your reply!

You mean that I can configure "mpls local-label add eos 33 ip4-lookup-in-table 
1"to pop the inner label,and use "mpls local-label add non-eos 34  
mpls-lookup-in-table 0" 
to pop the outer label. Am I right?

Thanks,
Xyxue

From: Neale Ranns (nranns)
Date: 2017-05-23 15:18
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] MPLS LABEL
Hi Xyxue,

MPLS labels are popped once they have been used in the lookup stage. The path 
(i.e. the config after the ‘via’ keyword) describes whether a new label should 
be pushed, so the absence of an out-label keyword there means that the router 
will be seen to pop the label.

These configs then;
  1) mpls local-label 33 ip4-lookup-in-table 0
   removes label 33 and does an IP lookup in Table-ID 0
2) mpls local-label 33 via 2.1.1.2  host-eth0 
   remove label 33, does not add another, and forwards to 2.1.1.1 on 
host-eth0 (this is probably what you want)
3) mpls local-label 33 via 2.1.1.2  host-eth0 out-label 66
   removes label 33, then adds 66 and forwards via 2.1.1.2 on host-eth0

If you add all three statements, then that’s ECMP. The hash algorithm for MPLS 
uses only the packets MPLS label, which is always 33, so it’ll only every take 
one of these choices.

Hth,
neale

From:  on behalf of 薛欣颖 
Date: Tuesday, 23 May 2017 at 07:28
To: vpp-dev 
Subject: Re: [vpp-dev] MPLS LABEL

Hi guys,

How can I configure label pop in Egress node?

That's my configure in my vpp , and the label didn't pop :

 set interface mpls  host-eth1   enable 
 set interface mpls  host-eth0   enable
 mpls local-label 33 ip4-lookup-in-table 0
 mpls local-label 33 via 2.1.1.2  host-eth0 
 mpls local-label 33 via 2.1.1.2  host-eth0 out-label 66
 ip route add 192.168.1.0/24 via 2.1.1.2 host-eth0 out-label 66 
 mpls tunnel add via 2.1.1.2 host-eth0 out-label 66
 set int state mpls-tunnel0 up
 ip route add 192.168.1.0/24 via mpls-tunnel0

What's wrong with my configuration ? Did I miss any configuration?

Thanks,
xyxue

From: xy...@fiberhome.com
Date: 2017-05-23 11:43
To: vpp-dev
Subject: MPLS LABEL

Hi guys,

I can configure mpls  out-label with "ip route add 1.1.1.1/24 via 1.1.2.1 
GigE0/0/0/0 out-label 123".
How can I configure  mpls local-label?

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS LABEL

2017-05-23 Thread 薛欣颖

Hi neale,

Thank you very much for your reply!

You mean that I can configure "mpls local-label add eos 33 ip4-lookup-in-table 
1"to pop the inner label,and use "mpls local-label add non-eos 34  
mpls-lookup-in-table 0" 
to pop the outer label. Am I right?

Thanks,
Xyxue

 
From: Neale Ranns (nranns)
Date: 2017-05-23 15:18
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] MPLS LABEL
Hi Xyxue,
 
MPLS labels are popped once they have been used in the lookup stage. The path 
(i.e. the config after the ‘via’ keyword) describes whether a new label should 
be pushed, so the absence of an out-label keyword there means that the router 
will be seen to pop the label.
 
These configs then;
  1) mpls local-label 33 ip4-lookup-in-table 0
   removes label 33 and does an IP lookup in Table-ID 0
2) mpls local-label 33 via 2.1.1.2  host-eth0 
   remove label 33, does not add another, and forwards to 2.1.1.1 on 
host-eth0 (this is probably what you want)
3) mpls local-label 33 via 2.1.1.2  host-eth0 out-label 66
   removes label 33, then adds 66 and forwards via 2.1.1.2 on host-eth0
 
If you add all three statements, then that’s ECMP. The hash algorithm for MPLS 
uses only the packets MPLS label, which is always 33, so it’ll only every take 
one of these choices.
 
Hth,
neale
 
 
From:  on behalf of 薛欣颖 
Date: Tuesday, 23 May 2017 at 07:28
To: vpp-dev 
Subject: Re: [vpp-dev] MPLS LABEL
 
Hi guys,

How can I configure label pop in Egress node?

That's my configure in my vpp , and the label didn't pop :

 set interface mpls  host-eth1   enable 
 set interface mpls  host-eth0   enable
 mpls local-label 33 ip4-lookup-in-table 0
 mpls local-label 33 via 2.1.1.2  host-eth0 
 mpls local-label 33 via 2.1.1.2  host-eth0 out-label 66
 ip route add 192.168.1.0/24 via 2.1.1.2 host-eth0 out-label 66 
 mpls tunnel add via 2.1.1.2 host-eth0 out-label 66
 set int state mpls-tunnel0 up
 ip route add 192.168.1.0/24 via mpls-tunnel0

What's wrong with my configuration ? Did I miss any configuration?


Thanks,
xyxue
 
From: xy...@fiberhome.com
Date: 2017-05-23 11:43
To: vpp-dev
Subject: MPLS LABEL
 
Hi guys,
 
I can configure mpls  out-label with "ip route add 1.1.1.1/24 via 1.1.2.1 
GigE0/0/0/0 out-label 123".
How can I configure  mpls local-label?
 
Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Assert appears when configuring MPLS tunnel

2017-05-23 Thread Neale Ranns (nranns)

Hi Xyxue,

Nothing wrong with that config. But there is a bug in VPP. I’ll fix that ASAP.

Thanks,
neale

From:  on behalf of 薛欣颖 
Date: Tuesday, 23 May 2017 at 07:52
To: vpp-dev 
Subject: [vpp-dev] Assert appears when configuring MPLS tunnel

Hi guys,

Why the assert appear on version 17.07, is there anything wrong with my 
configuration?
DBGvpp# mpls local-label add eos 33 ip4-lookup-in-table 1
DBGvpp# mpls local-label add non-eos 34  mpls-lookup-in-table 0
DBGvpp# mpls tunnel add via 2.1.1.1 host-eth1 out-label 1023
DBGvpp# set int state mpls-tunnel0 up
DBGvpp# ip route add 192.168.1.0/24 via mpls-tunnel0 out-label 1024
0: /home/vpp_1707/vpp/build-data/../src/vnet/dpo/dpo.c:329 (dpo_get_next_node) 
assertion `NULL != dpo_nodes[parent_type]' fails
Aborted
/ # Connection closed by foreign host.

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Assert appears when configuring MPLS tunnel

2017-05-23 Thread 薛欣颖


Hi guys,

Why the assert appear on version 17.07, is there anything wrong with my 
configuration?
DBGvpp# mpls local-label add eos 33 ip4-lookup-in-table 1
DBGvpp# mpls local-label add non-eos 34  mpls-lookup-in-table 0
DBGvpp# mpls tunnel add via 2.1.1.1 host-eth1 out-label 1023
DBGvpp# set int state mpls-tunnel0 up
DBGvpp# ip route add 192.168.1.0/24 via mpls-tunnel0 out-label 1024
0: /home/vpp_1707/vpp/build-data/../src/vnet/dpo/dpo.c:329 (dpo_get_next_node) 
assertion `NULL != dpo_nodes[parent_type]' fails
Aborted
/ # Connection closed by foreign host.

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS LABEL

2017-05-23 Thread 薛欣颖

Hi guys,

How can I configure label pop in Egress node?

That's my configure in my vpp , and the label didn't pop :

 set interface mpls  host-eth1   enable 
 set interface mpls  host-eth0   enable
 mpls local-label 33 ip4-lookup-in-table 0
 mpls local-label 33 via 2.1.1.2  host-eth0 
 mpls local-label 33 via 2.1.1.2  host-eth0 out-label 66
 ip route add 192.168.1.0/24 via 2.1.1.2 host-eth0 out-label 66 
 mpls tunnel add via 2.1.1.2 host-eth0 out-label 66
 set int state mpls-tunnel0 up
 ip route add 192.168.1.0/24 via mpls-tunnel0

What's wrong with my configuration ? Did I miss any configuration?

Thanks,
xyxue
 
From: xy...@fiberhome.com
Date: 2017-05-23 11:43
To: vpp-dev
Subject: MPLS LABEL

Hi guys,

I can configure mpls  out-label with "ip route add 1.1.1.1/24 via 1.1.2.1 
GigE0/0/0/0 out-label 123".
How can I configure  mpls local-label?

Thanks,
xyxue
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

48 matches

Mail list logo