It may be extreme, but perhaps detect if any namespace is configured (whether 
we’re running in a namespace or in the default) and then fall back to the 
safest behavior (with a note in the startup output saying so).

Is it reasonable? Could add a flag that always binds every device found for 
people who explicitly want the current behavior.

I suppose if we’re in the default ns we could iterate every other ns to ignore 
ports mapped to them but it feels fragile somehow.

Chris.


On 5/24/17, 04:33, "Damjan Marion" <dmarion.li...@gmail.com> wrote:

    Yeah, I’m aware of this issue but I don’t have any good idea how to address 
it.
    
    We can disable unbind if we detect that we are running inside namespace, 
but that will not fix problem in opposite direction, when specific interface is 
mapped to namespace and vpp running in global.
    
    any ideas?
    
    
    > On 24 May 2017, at 05:14, Luke, Chris <chris_l...@comcast.com> wrote:
    > 
    > 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 <chris_l...@cable.comcast.com>
    >> 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 <chris_l...@comcast.com>
    >> 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 <id>
    >>>  ...
    >>> }
    >>> 
    >>> 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 0000:00:03.0 as host
    >>>> interface
    >>>> enp0s3 is up
    >>>> vlib_pci_bind_to_uio: Skipping PCI device 0000:00:08.0 as host
    >>>> interface
    >>>> enp0s8 is up
    >>>> vlib_pci_bind_to_uio: Skipping PCI device 0000: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:0x34000000, len:8388608, virt:0x7facdbc00000,
    >>>> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 Segment 1:
    >>>> phys:0x70800000, len:2097152, virt:0x7facdb800000, socket_id:0,
    >>>> hugepage_sz:2097152, nchannel:0, nrank:0 Segment 2: phys:0x70c00000,
    >>>> len:257949696, virt:0x7fac76200000, 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:
    >>>> /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
    >>>> vpp[1264]: dpdk_ipsec_process:239: not enough Cryptodevs, default to
    >>>> OpenSSL IPsec
    >>>> vpp[1264]: dpdk_lib_init:186: DPDK drivers found 3 ports...
    >>>> vpp[1264]: svm_client_scan_this_region_nolock:1140: /vpe-api: cleanup
    >>>> ghost pid 1180
    >>>> vpp[1264]: svm_client_scan_this_region_nolock:1140: /global_vm:
    >>>> cleanup ghost pid 1180
    >>>> vpp[1264]: received signal SIGINT, PC 0x7f2e2d976a37 DPDK physical
    >>>> memory
    >>>> layout:
    >>>> Segment 0: phys:0x34000000, len:8388608, virt:0x7f2d9ec00000,
    >>>> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 Segment 1:
    >>>> phys:0x70800000, len:2097152, virt:0x7f2d9e800000, socket_id:0,
    >>>> hugepage_sz:2097152, nchannel:0, nrank:0 Segment 2: phys:0x70c00000,
    >>>> len:257949696, virt:0x7f2d39200000, socket_id:0, hugepage_sz:2097152,
    >>>> nchannel:0, nrank:0
    >>>> 
    >>>> 4 - In another shell I can see all interfaces being removed (except 
lo):
    >>>> # ip monitor link
    >>>> 2: enp0s3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state
    >> DOWN
    >>>> group default
    >>>>    link/ether 08:00:27:33:82:8a brd ff:ff:ff:ff:ff:ff Deleted 2: 
enp0s3:
    >>>> <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
    >> default
    >>>>    link/ether 08:00:27:33:82:8a brd ff:ff:ff:ff:ff:ff
    >>>> 3: enp0s8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state
    >> DOWN
    >>>> group default
    >>>>    link/ether 08:00:27:b1:f8:99 brd ff:ff:ff:ff:ff:ff Deleted 3: 
enp0s8:
    >>>> <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
    >> default
    >>>>    link/ether 08:00:27:b1:f8:99 brd ff:ff:ff:ff:ff:ff
    >>>> 4: enp0s9: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state
    >> DOWN
    >>>> group default
    >>>>    link/ether 08:00:27:be:61:9f brd ff:ff:ff:ff:ff:ff Deleted 4: 
enp0s9:
    >>>> <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
    >> default
    >>>>    link/ether 08:00:27:be:61:9f brd ff:ff:ff:ff:ff:ff
    >>>> 
    >>>> Any help would be appreciated.
    >>>> 
    >>>> Best Regards,
    >>>> --
    >>>> Renato Westphal
    >>>> _______________________________________________
    >>>> vpp-dev mailing list
    >>>> vpp-dev@lists.fd.io
    >>>> https://lists.fd.io/mailman/listinfo/vpp-dev
    >>> 
    >> 
    >> 
    >> 
    >> --
    >> Renato Westphal
    > 
    > _______________________________________________
    > vpp-dev mailing list
    > vpp-dev@lists.fd.io
    > https://lists.fd.io/mailman/listinfo/vpp-dev
    
    
    

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to