date:20181023

Re: [ovs-discuss] Problems executing decap(eth)+encap(eth) actions

2018-10-23 Thread Ben Pfaff

Greg, can you take a look at this when you have some time?

On Fri, Oct 19, 2018 at 10:39:00AM +0200, Jaime Caamaño Ruiz wrote:
> Hello
> 
> When using nsh encapsulation, it's useful to normalize your pipeline to
> packet_type=nsh, poping an ethernet header on input if necessary and
> pushing an ethernet header again if required before output.
> 
> But it seems to be problematic:
> 
> ---
> 2018-10-18T13:10:59.196Z|00010|dpif(handler3)|WARN|system@ovs-system:
> execute pop_eth,push_eth(src=fe:16:3e:c1:9e:87,dst=fa:16:3e:c1:9e:87),5
> failed (Invalid argument) on packet
> vlan_tci=0x,dl_src=fa:16:3e:c2:e6:68,dl_dst=fe:16:3e:c2:e6:68,dl_ty
> pe=0x894f,nsh_flags=0,nsh_ttl=63,nsh_mdtype=1,nsh_np=3,nsh_spi=0x1a,nsh
> _si=254,nsh_c1=0xc0a82a01,nsh_c2=0x3,nsh_c3=0x0,nsh_c4=0x9100,nw_pr
> oto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
>  with metadata
> skb_priority(0),tunnel(tun_id=0x0,src=192.168.42.1,dst=192.168.42.3,ttl
> =64,tp_src=47656,tp_dst=4789,flags(key)),skb_mark(0),in_port(4) mtu 0
> ---
> 
> Looking at the code datapath/flow_netlink.c @ __ovs_nla_copy_actions:
> 
> case OVS_ACTION_ATTR_PUSH_ETH:
> /* Disallow pushing an Ethernet header if one
>  * is already present */
> if (mac_proto != MAC_PROTO_NONE)
> return -EINVAL;
> mac_proto = MAC_PROTO_NONE;
> break;
> 
> case OVS_ACTION_ATTR_POP_ETH:
> if (mac_proto != MAC_PROTO_ETHERNET)
> return -EINVAL;
> if (vlan_tci & htons(VLAN_TAG_PRESENT))
> return -EINVAL;
> mac_proto = MAC_PROTO_ETHERNET;
> break;
> 
> 
> Isn't the mac_proto set inverted here, should'nt it look like this?
> 
> 
> case OVS_ACTION_ATTR_PUSH_ETH:
> /* Disallow pushing an Ethernet header if one
>  * is already present */
> if (mac_proto != MAC_PROTO_NONE)
> return -EINVAL;
> mac_proto = MAC_PROTO_ETHERNET;
> break;
> 
> case OVS_ACTION_ATTR_POP_ETH:
> if (mac_proto != MAC_PROTO_ETHERNET)
> return -EINVAL;
> if (vlan_tci & htons(VLAN_TAG_PRESENT))
> return -EINVAL;
> mac_proto = MAC_PROTO_NONE;
> break;
> 
> 
> BR
> Jaime.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Multiple MPLS labels support in OVS

2018-10-23 Thread Ben Pfaff

On Mon, Oct 22, 2018 at 10:40:10AM +0530, Martin Varghese wrote:
> HI
> I need to support a use case where i need to send(push) and receive(pop)
> multiple MPLS labels in OVS
> 
> The description regarding the support for more than one MPLS labels is
> contradicting in the man pages of ovs-ofctl and ovs-fields.
> 
> The man page of ovs-ofctl  does not mention the support of more than one
> MPLS label.
> 
> *push_mpls:ethertype*
> 
> -  *A limitation of the implementation is that processing  of
> actions  will stop if push_mpls follows another push_mpls unless there
> is a pop_mpls in between.*
> 
> *pop_mpls:ethertype*
> 
> -  *Currently  the  implementation  restricts  ethertype  to  a
> non-MPLS Ethertype and thus pop_mpls should  only  be  applied  to packets
> with an MPLS label stack depth of one.*
> 
> Whereas the man page of ovs-fields mention a support of up to 3 MPLS labels.
> 
> *Unlike the other encapsulations supported by OpenFlow and Open
> vSwitch, MPLS labels are routinely used in ``stacks’’ two or three
> deep and sometimes even deeper. Open vSwitch currently supports up to
> three labels.*
> 
> 
> 
> Could someone please clarify

OVS supports up to 3 labels.

We'll update the documentation.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Tuning ovs

2018-10-23 Thread Ben Pfaff

I recommend testing the performance.

On Tue, Oct 23, 2018 at 05:02:12AM +, Srinivas wrote:
> Thanks Ben. Just to give a bit of background, we have a 32 cpu system. If i 
> bring up ovs using the default i see that ovs-vswitchd takes around 290 MB of 
> memory. Majority of this is coming from the stack size consumption for the 
> various threads.If i restrict the other-config:n-handler-threads and  
> other-config:n-revalidator-threads  to 1, i see the rss of ovs-vswitchd comes 
> down to 40MB. 
> I am looking to see if the extra ~= 250 MB is really needed for my case where 
> i would not have any flow rules in the user space and i would be using ovs as 
> a plain L2 switch. I would be having 3-4 ovs bridges though at the max.
> 
> truly, Srinivas. 
> 
> On Saturday, 20 October, 2018, 4:27:05 AM IST, Ben Pfaff  
> wrote:  
>  
>  On Fri, Oct 19, 2018 at 07:26:14PM +, Srinivas via discuss wrote:
> > Hello all,We are starting with ovs and want to use it as
> > a)  a L2 switch with vlan tagging on the guest vm ports.b) no openflow 
> > rules will be configured.c) We will have 4 -5 bridges created on the system 
> > with each bridge having a corresponding  bond interface along with the 
> > guest vtap's.
> > Given the above, how do we tune ovs-vsctl  parameters.?Does each bridge 
> > correspond to a data path? If so what should we set the 
> > other-config:n-handler-threads and  other-config:n-revalidator-threads to?
> > 
> > We want to make sure the ovs-vswitchd starts off with the right number of 
> > threads.
> 
> We try to make OVS have good defaults, so that it isn't necessary to do
> this kind of configuration at all.  I recommend testing the performance
> before considering any tuning.
>   
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 40 Gbit Traffic Test Problem

2018-10-23 Thread mehmetyaren

Hi,

We want to send 40 Gbit traffic with t-rex traffic generator, we are using 40 
Gbit supported DPDK NIC, but when we generate traffic as 40 Gbit, it can not 
transmit all traffics just 10 Gbit traffic is transmitted by DPDK NIC. We are 
using Open vSwitch 2.10.0 version and DPDK 17.11.2 version.
 We made some configuration to increasing core number for dpdk ports with below 
commands;

ovs-vsctl set interface dpdk0 options:n_rxq=4  
other_config:pmd-rxq-affinity="0:0,1:1,2:2,3:3"
ovs-vsctl set interface dpdk1 options:n_rxq=4  
other_config:pmd-rxq-affinity="0:4,1:5,2:6,3:7"

And we have seen all pmd capacities are not used by dpdk ports as seen below 
results;

 sudo ovs-appctl dpif-netdev/pmd-rxq-show pmd thread numa_id 0 core_id 0:

  isolated : true
  port: dpdk0 queue-id:  0  pmd usage: 19 %
pmd thread numa_id 1 core_id 1:
  isolated : true
  port: dpdk0 queue-id:  1  pmd usage: 20 %
pmd thread numa_id 0 core_id 2:
  isolated : true
  port: dpdk0 queue-id:  2  pmd usage: 20 %
pmd thread numa_id 1 core_id 3:
  isolated : true
  port: dpdk0 queue-id:  3  pmd usage: 21 %
pmd thread numa_id 0 core_id 4:
  isolated : true
  port: dpdk1 queue-id:  0  pmd usage: 13 %
pmd thread numa_id 1 core_id 5:
  isolated : true
  port: dpdk1 queue-id:  1  pmd usage: 13 %
pmd thread numa_id 0 core_id 6:
  isolated : true
  port: dpdk1 queue-id:  2  pmd usage: 13 %
pmd thread numa_id 1 core_id 7:
  isolated : true
  port: dpdk1 queue-id:  3  pmd usage: 15 %


Can anyone help me ?

Mehmet.



Sent from Mail for Windows 10

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] vhostuser-client for containers

2018-10-23 Thread Subrata Nath via discuss

Hi,

1)I am working with DPDK 18.02 and OVS 2.10 for containers(virtio-user
interface). it’s found that vhostuser is deprecated there and it’s
recommended to use “vhostuser-client” type.  Error log is shown below. I
couldn’t find any documentation how to use this “vhostuser-client” with the
testpmd inside the container. All the documentation for running testpmd,
inside the container, is with socket created by OVS for vhostuser interface
(
“--vdev=net_virtio_user2,mac=00:00:00:00:00:02,path=/usr/local/var/run/openvswitch/vhost_user2”)
only. Documentation of “vhostuser-client” is  with QEMU only and no
documentation is available for the containers.

*2018-10-23T06:16:25.235Z|2|dpif(revalidator6)|WARN|netdev@ovs-netdev:
failed to put[modify] (Invalid argument)
ufid:d060efe9-3f5c-4f9c-a5c1-70f934148956
skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(3),packet_type(ns=0,id=0),eth(src=ec:3e:f7:07:2b:00,dst=01:00:5e:00:00:01),eth_type(0x8100),vlan(vid=1600,pcp=6/0x0),encap(eth_type(0x0800),ipv4(src=10.40.64.129/0.0.0.0,dst=224.0.0.1/0.0.0.0,proto=2/0,tos=0xc0/0,ttl=1/0,frag=no)
),
actions:userspace(pid=0,slow_path(match))*

*2018-10-23T06:16:31.332Z|3|dpif_netdev(revalidator6)|ERR|internal
error parsing flow key
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(3),packet_type(ns=0,id=0),eth(src=90:e2:ba:b3:6c:ac,dst=01:00:5e:4d:7c:d5),eth_type(0x8100),vlan(vid=1600,pcp=0),encap(eth_type(0x0800),ipv4(src=10.40.64.135,dst=239.77.124.213,proto=2,tos=0xc0,ttl=1,frag=no))*

*2018-10-23T06:16:31.332Z|4|dpif_netdev(revalidator6)|ERR|internal
error parsing flow key
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(3),packet_type(ns=0,id=0),eth(src=ec:3e:f7:07:2b:00,dst=01:00:5e:00:00:01),eth_type(0x8100),vlan(vid=1600,pcp=6),encap(eth_type(0x0800),ipv4(src=10.40.64.129,dst=224.0.0.1,proto=2,tos=0xc0,ttl=1,frag=no))*

*2018-10-23T06:16:31.332Z|5|dpif(revalidator6)|WARN|netdev@ovs-netdev:
failed to put[modify] (Invalid argument)
ufid:dd38c0b0-e35f-4710-a2a3-d62279dada2f
skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(3),packet_type(ns=0,id=0),eth(src=90:e2:ba:b3:6c:ac,dst=01:00:5e:4d:7c:d5),eth_type(0x8100),vlan(vid=1600,pcp=0/0x0),encap(eth_type(0x0800),ipv4(src=10.40.64.135/0.0.0.0,dst=239.77.124.213/0.0.0.0,proto=2/0,tos=0xc0/0,ttl=1/0,frag=no)
),
actions:userspace(pid=0,slow_path(match))*

*2018-10-23T06:16:31.332Z|6|dpif(revalidator6)|WARN|netdev@ovs-netdev:
failed to put[modify] (Invalid argument)
ufid:d060efe9-3f5c-4f9c-a5c1-70f934148956
skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(3),packet_type(ns=0,id=0),eth(src=ec:3e:f7:07:2b:00,dst=01:00:5e:00:00:01),eth_type(0x8100),vlan(vid=1600,pcp=6/0x0),encap(eth_type(0x0800),ipv4(src=10.40.64.129/0.0.0.0,dst=224.0.0.1/0.0.0.0,proto=2/0,tos=0xc0/0,ttl=1/0,frag=no)
),
actions:userspace(pid=0,slow_path(match))*

*2018-10-23T07:12:16.802Z|00096|dpdk|INFO|VHOST_CONFIG: vhost-user server:
socket created, fd: 57*

*2018-10-23T07:12:16.803Z|00097|netdev_dpdk|INFO|Socket
/usr/local/var/run/openvswitch/vhost_user2 created for vhost-user port
vhost_user2*

*2018-10-23T07:12:16.803Z|00098|dpdk|INFO|VHOST_CONFIG: bind to
/usr/local/var/run/openvswitch/vhost_user2*
*2018-10-23T07:12:16.803Z|00099|netdev_dpdk|WARN|dpdkvhostuser ports are
considered deprecated;  please migrate to dpdkvhostuserclient ports.*

2)  We are trying our if the OVS can be used as load balancer. As our
backend microservices container will be spread across multiple servers of
K8s cluster, is it possible to have a single DPDK OVS container in a single
server only instead of running it in all the servers. As per the
documentation, testpmd is running with the EAL option
 
“--vdev=net_virtio_user2,mac=00:00:00:00:00:02,path=/usr/local/var/run/openvswitch/vhost_user2”.
Hence it’s expected the DPDK-OVS created vhost-user socket is in the same
server. Is it possible, to access this socket over IP as the DPDK-OVS is
different server? With this, we can have a single OVS as Load balancer.

Regards,
Subrata
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Issues configuring OVS-DPDK in openstack queens

2018-10-23 Thread O Mahony, Billy

Hi Manojawa,

So is there any remaining entry br-flat entry in the ovsdb? Does it give any 
clue to the reason – there may be a free-form ‘status’ or ‘info’ field for that 
purpose.

I can understand the situation where a bridge might get incorrectly configured 
but I can’t understand why it is deleted by something other than the agent.

Maybe it tries to create the bridge, there is some error so it decides to 
delete it. Are there more detailed log levels available for the agent? You may 
be able to turn on more detailed logging for the bridge logging in OvS too.

/Billy.

From: Manojawa Paritala [mailto:manojaw...@biarca.com]
Sent: Tuesday, October 23, 2018 12:16 PM
To: O Mahony, Billy 
Cc: ovs-discuss@openvswitch.org; ovs-...@openvswitch.org
Subject: Re: [ovs-dev] Issues configuring OVS-DPDK in openstack queens

Hi Billy,

Thank you for your reply.

1. Huge pages are properly set. Based on the dpdk configuration 
dpdk-socket-mem="4096,4096", 8 pages were created under /dev/hugepages.
2. dpdk-p0 is not attached to br-flat1. Actually I defined the bridge as 
br-flat1.
3. Yes,  'ovs-vsctl show'  does not show br-flat1. As soon as I add the below 
entries in openvswitch-agent.ini and restart the neutron-openmvswitch-agent 
service, br-flat1 is getting deleted. I can see that in the ovs-vswitch logs 
and also in the output of "ovsdb-tool -mmm show-log"

datapath_type=netdev
vhostuser_socket_dir=/var/run/openvswitch

4. I do not see any errors in then neutron-openvswitch-agent logs, except for 
the below which are displayed after the bridge is deleted.

ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-99a234e3-c943-4234-8c4d-f0fdc594df8f - - - - -] Bridge br-flat1 for 
physical network flat does not exist. Agent terminated!

Thanks & Regards,
PVMJ

On Tue, Oct 23, 2018 at 3:06 PM O Mahony, Billy 
mailto:billy.o.mah...@intel.com>> wrote:
Hi,

I don't see any errors relating to the dpdk interfaces. But it is also not 
clear where the user-space drivers are bound and the hugepage memory is set up. 
So double check those two items.

Is the dpdk-p0 interface being attached to br-flat? Even if there are issues 
with the dpdk port the bridge should not be deleted (at least not automatically 
by OvS).

Can you confirm with 'ovs-vsctl show' that the br-flat is actually not present 
after the agent is restarted. And that the dpdk-p0 is not reporting an error.

What does the neutron-openmvswitch-agent logs say?

Also run ovsdb-tool -mmm show-log which might give a clue as to when and how 
br-flat is being modified.

Regards,
Billy

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org 
> [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of 
> Manojawa Paritala
> Sent: Monday, October 22, 2018 3:31 PM
> To: ovs-discuss@openvswitch.org; 
> ovs-...@openvswitch.org
> Subject: [ovs-dev] Issues configuring OVS-DPDK in openstack queens
>
> Hello All,
>
> On a 3 node (one controller + 2 compute), we configured Openstack Queens
> using OSA with OVS. On all the nodes, we defined br-mgmt as linux bridge, br-
> tun as private network and br-flat as external.
> Installation was successful and we could create networks and instances on
> Openstack.
>
> Below are the versions of the OVS packages used on each node.
>
> Controller :- openstack-vswitch - 2.9.0
> Computes :- openstack-vswitch-dpdk - 2.9.0 (as we wanted to configure dpdk on
> the compute hosts)
>
> The openstack-vswitch-dpdk 2.9.0 package that we installed had dpdk version
> 17.11.3. When we tried to enable DPDK it failed with the below error.
>
> dpdk|ERR|DPDK not supported in this copy of Open vSwitch
>
> So, we downloaded the sources for dpdk 17.11.4 and openvswitch 2.9.2, built
> openvswitch with dpdk as suggested in the below official link.
> No issues on Openstack or OVS.
> http://docs.openvswitch.org/en/latest/intro/install/dpdk/
>
> Then, we added the below parameters to OVS and everything looked ok.
> No issues in Openstack or OVS.
>
> $ovs-vsctl get Open_vSwitch . other_config {dpdk-extra="-n 2", 
> dpdk-init="true",
> dpdk-lcore-mask="0x3000", dpdk-socket-mem="4096,4096", pmd-
> cpu-mask="0xf3c", vhost-iommu-support="true"}
>
> Then on the compute node, in openvswitch_agent.ini file - OVS section, I added
> the below (based on the link
> https://docs.openstack.org/neutron/pike/contributor/internals/ovs_vhostuser.h
> tml
> )
> and restarted neutron-openmvswitch-agent service.
>
> datapath_type=netdev
> vhostuser_socket_dir=/var/run/openvswitch
>
> After the above change, bridge br-flat is getting deleted from OVS.
> Attached are the logs after I restart the neutron-openmvswitch-agent service 
> on
> the compute now. Not sure what the issue is.
>
> Can any of you please let me know if we are missing anything?
>
> Best Regards,
> PVMJ

Re: [ovs-discuss] [ovs-dev] Issues configuring OVS-DPDK in openstack queens

2018-10-23 Thread Manojawa Paritala

Hi Billy,

Thank you for your reply.

1. Huge pages are properly set. Based on the dpdk configuration
dpdk-socket-mem="4096,4096", 8 pages were created under /dev/hugepages.
2. dpdk-p0 is not attached to br-flat1. Actually I defined the bridge as
br-flat1.
3. Yes,  'ovs-vsctl show'  does not show br-flat1. As soon as I add the
below entries in openvswitch-agent.ini and restart the
neutron-openmvswitch-agent service, br-flat1 is getting deleted. I can see
that in the ovs-vswitch logs and also in the output of "ovsdb-tool -mmm
show-log"

datapath_type=netdev
vhostuser_socket_dir=/var/run/openvswitch

4. I do not see any errors in then neutron-openvswitch-agent logs, except
for the below which are displayed after the bridge is deleted.

ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-99a234e3-c943-4234-8c4d-f0fdc594df8f - - - - -] Bridge br-flat1 for
physical network flat does not exist. Agent terminated!

Thanks & Regards,
PVMJ

On Tue, Oct 23, 2018 at 3:06 PM O Mahony, Billy 
wrote:

> Hi,
>
> I don't see any errors relating to the dpdk interfaces. But it is also not
> clear where the user-space drivers are bound and the hugepage memory is set
> up. So double check those two items.
>
> Is the dpdk-p0 interface being attached to br-flat? Even if there are
> issues with the dpdk port the bridge should not be deleted (at least not
> automatically by OvS).
>
> Can you confirm with 'ovs-vsctl show' that the br-flat is actually not
> present after the agent is restarted. And that the dpdk-p0 is not reporting
> an error.
>
> What does the neutron-openmvswitch-agent logs say?
>
> Also run ovsdb-tool -mmm show-log which might give a clue as to when and
> how br-flat is being modified.
>
> Regards,
> Billy
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Manojawa Paritala
> > Sent: Monday, October 22, 2018 3:31 PM
> > To: ovs-discuss@openvswitch.org; ovs-...@openvswitch.org
> > Subject: [ovs-dev] Issues configuring OVS-DPDK in openstack queens
> >
> > Hello All,
> >
> > On a 3 node (one controller + 2 compute), we configured Openstack Queens
> > using OSA with OVS. On all the nodes, we defined br-mgmt as linux
> bridge, br-
> > tun as private network and br-flat as external.
> > Installation was successful and we could create networks and instances on
> > Openstack.
> >
> > Below are the versions of the OVS packages used on each node.
> >
> > Controller :- openstack-vswitch - 2.9.0
> > Computes :- openstack-vswitch-dpdk - 2.9.0 (as we wanted to configure
> dpdk on
> > the compute hosts)
> >
> > The openstack-vswitch-dpdk 2.9.0 package that we installed had dpdk
> version
> > 17.11.3. When we tried to enable DPDK it failed with the below error.
> >
> > dpdk|ERR|DPDK not supported in this copy of Open vSwitch
> >
> > So, we downloaded the sources for dpdk 17.11.4 and openvswitch 2.9.2,
> built
> > openvswitch with dpdk as suggested in the below official link.
> > No issues on Openstack or OVS.
> > http://docs.openvswitch.org/en/latest/intro/install/dpdk/
> >
> > Then, we added the below parameters to OVS and everything looked ok.
> > No issues in Openstack or OVS.
> >
> > $ovs-vsctl get Open_vSwitch . other_config {dpdk-extra="-n 2",
> dpdk-init="true",
> > dpdk-lcore-mask="0x3000", dpdk-socket-mem="4096,4096", pmd-
> > cpu-mask="0xf3c", vhost-iommu-support="true"}
> >
> > Then on the compute node, in openvswitch_agent.ini file - OVS section, I
> added
> > the below (based on the link
> >
> https://docs.openstack.org/neutron/pike/contributor/internals/ovs_vhostuser.h
> > tml
> > )
> > and restarted neutron-openmvswitch-agent service.
> >
> > datapath_type=netdev
> > vhostuser_socket_dir=/var/run/openvswitch
> >
> > After the above change, bridge br-flat is getting deleted from OVS.
> > Attached are the logs after I restart the neutron-openmvswitch-agent
> service on
> > the compute now. Not sure what the issue is.
> >
> > Can any of you please let me know if we are missing anything?
> >
> > Best Regards,
> > PVMJ
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Starting OVS w/ DPDK ...

2018-10-23 Thread Andrzej Ostruszka

Flavio

Thank you again for trying to help me.  Luckily I've solved the problem.
 So here I'll just document it for the benefit of other people with the
same problem.

On 10/19/2018 08:12 PM, Flavio Leitner wrote:
> On Mon, Oct 08, 2018 at 11:52:24AM +0200, Andrzej Ostruszka wrote:
[...]
>> ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching
>> device '08:00.0' to DPDK.  See ovs-vswitchd log for details.
>> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
>>
>> and in there the confirmation from DPDK:
>>
>> 2018-10-08T09:38:28.234Z|00058|dpdk|ERR|EAL: Cannot find unplugged
>> device (08:00.0)
>> 2018-10-08T09:38:28.234Z|00059|netdev_dpdk|WARN|Error attaching device
>> '08:00.0' to DPDK
>> 2018-10-08T09:38:28.234Z|00060|netdev|WARN|dpdk-p0: could not set
>> configuration (Invalid argument)

The key word in the above log was "unplugged".  What actually happened
when I have given PCI address is that OvS tried to attach the driver
when it already has been attached.

So it looks like upon the startup OvS does a scan and attaches the ports
(excerpt from the log):
|INFO|EAL: PCI device :01:00.0 on NUMA socket -1
|WARN|EAL:   Invalid NUMA socket, default to 0
|INFO|EAL:   probe driver: 15b3:1019 net_mlx5
|INFO|PMD: net_mlx5: PCI information matches, using device "mlx5_0"
(SR-IOV: false)
|INFO|PMD: net_mlx5: 1 port(s) detected

So I've taken a look at the code and saw that OvS takes the dpdk-devargs
and first searches for the port by that name and if not found then it
tries to attach/hotplug using this value.  Thus the solution was to
change the value of dpdk-devargs to the name of the port (mlx5_0 and
mlx5_1) instead of PCI address.  So with the following config everything
works just fine - I guess the documentation could be updated a bit though.

# ovs-vsctl show
67be421b-d397-4173-b1d5-e7d80f641daa
Bridge "br0"
Port "dpdk-p1"
Interface "dpdk-p1"
type: dpdk
options: {dpdk-devargs="mlx5_1"}
Port "br0"
Interface "br0"
type: internal
Port "dpdk-p0"
Interface "dpdk-p0"
type: dpdk
options: {dpdk-devargs="mlx5_0"}
ovs_version: "2.10.90"

Best regards
Andrzej
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Problems executing decap(eth)+encap(eth) actions

Re: [ovs-discuss] Multiple MPLS labels support in OVS

Re: [ovs-discuss] Tuning ovs

[ovs-discuss] 40 Gbit Traffic Test Problem

[ovs-discuss] vhostuser-client for containers

Re: [ovs-discuss] [ovs-dev] Issues configuring OVS-DPDK in openstack queens

Re: [ovs-discuss] [ovs-dev] Issues configuring OVS-DPDK in openstack queens

Re: [ovs-discuss] Starting OVS w/ DPDK ...

8 matches

Site Navigation

Mail list logo

Footer information