Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

2017-09-19 Thread Sun Paul
sorry about that

# ovs-vsctl get Open_vSwitch . other_config
{dpdk-init="true", n-dpdk-rxqs="2", pmd-cpu-mask="0x6"}

On Tue, Sep 19, 2017 at 8:02 PM, Flavio Leitner  wrote:
> On Tue, 19 Sep 2017 13:43:25 +0800
> Sun Paul  wrote:
>
>> Hi
>>
>> below is the output. currently, I am only able to set to use two CPU for PMD.
>
>
> I was referring to the output of
> ovs-vsctl get Open_vSwitch . other_config
>
> fbl
>
>>
>> # ovs-vsctl show
>> ea7f2b40-b7b3-4f11-a81f-cf25a56f8172
>> Bridge "gtp1"
>> Port "dpdk0"
>> Interface "dpdk0"
>> type: dpdk
>> options: {dpdk-devargs=":04:00.2", n_rxq="4"}
>> Port "gtp1"
>> Interface "gtp1"
>> type: internal
>> Port "dpdk1"
>> Interface "dpdk1"
>> type: dpdk
>> options: {dpdk-devargs=":04:00.3", n_rxq="4"}
>>
>>
>>
>> On Tue, Sep 19, 2017 at 4:09 AM, Flavio Leitner  wrote:
>> > On Mon, 18 Sep 2017 16:51:33 +0800
>> > Sun Paul  wrote:
>> >
>> >> Hi
>> >>
>> >> I have two interfaces mapped to DPDK, and run the OVS on top of it. I
>> >> tried to set the cpu mask, but I cannot only allocate more than 2 CPU
>> >> for pmd thread. any idea?
>> >>
>> >> # /usr/local/bin/ovs-appctl dpif-netdev/pmd-rxq-show
>> >> pmd thread numa_id 0 core_id 1:
>> >> isolated : false
>> >> port: dpdk0 queue-id: 0
>> >> pmd thread numa_id 0 core_id 2:
>> >> isolated : false
>> >> port: dpdk1 queue-id: 0
>> >
>> > Could you post the DPDK configuration and what do you want?
>> >
>> > Thanks,
>> > --
>> > Flavio
>> >
>
>
>
> --
> Flavio
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] How to submit a bug report

2017-09-19 Thread Llorente Santos Jesus
Finally got around to tracing this bug.
As indicated by Ben I used git bisect to find the issue. Very neat feature of 
git! 

Copy paste of my findings:

<<
Attending to the instructions received in the mailing list, I have managed to 
find the culprit via git bisect.
The bug I am experiencing seems to be fixed after removing the OVS GRE IPsec 
tunnel functionality.

Here is the log of the process:
```
$ git bisect log
git bisect start
# bad: [c298ef781c2d35d939fe163cbc2f41ea7b1cb8d1] Set release date for 2.7.0.
git bisect bad c298ef781c2d35d939fe163cbc2f41ea7b1cb8d1
# good: [f4b0e64cffb4777ff03d48621c3eadcf1d8c19f3] Set release date for 2.6.1.
git bisect good f4b0e64cffb4777ff03d48621c3eadcf1d8c19f3
# good: [4c714486187dada924f1e1fc2fdbec99cddd777f] Prepare for 2.6.0.
git bisect good 4c714486187dada924f1e1fc2fdbec99cddd777f
# bad: [048318e0726c94876e504de7b578f929e9f509a0] netdev: Count ports within 
mutex.
git bisect bad 048318e0726c94876e504de7b578f929e9f509a0
# bad: [b614c894ee55b07009f3e5b10ddec7556773fcc4] netdev-dpdk: Configure flow 
control only when necessary.
git bisect bad b614c894ee55b07009f3e5b10ddec7556773fcc4
# good: [cc4583aadd2a55b340bc7917305b41bbba29c9f2] ovn-northd: Add 
load-balancers to gateway routers.
git bisect good cc4583aadd2a55b340bc7917305b41bbba29c9f2
# good: [9ef3a410b2d93ae6890c6e831dd3ed84d3c374d9] datapath-windows: Add define 
for last module number
git bisect good 9ef3a410b2d93ae6890c6e831dd3ed84d3c374d9
# good: [9e9d0384910e8d1e96463be19378de3fe9d64877] openvswitch: deprecates 
support for IPsec tunnel port.
git bisect good 9e9d0384910e8d1e96463be19378de3fe9d64877
# bad: [dd0dc9eda0e0b4a6b2f8f4dee442be6865e60c89] revalidator: Reuse xlate_ukey 
from deletion.
git bisect bad dd0dc9eda0e0b4a6b2f8f4dee442be6865e60c89
# bad: [9f02d70c11e14366f2136caaedcebd629551a131] ofp-actions: Style fixes.
git bisect bad 9f02d70c11e14366f2136caaedcebd629551a131
# good: [5e8bc3c549ca9bfa02c5525c02cb4ee12ef1f06e] ovsdb: Fix memory leak when 
disposing 'replication_dbs'
git bisect good 5e8bc3c549ca9bfa02c5525c02cb4ee12ef1f06e
# bad: [9120cfc05cd49d4ba1a47eb97e6407e72a5d33f7] netdev-linux: Use ethtool 
when miimon fails.
git bisect bad 9120cfc05cd49d4ba1a47eb97e6407e72a5d33f7
# bad: [2b02d770c4cb381ec32cd4b7b1e991c42b448884] openvswitch: Allow external 
IPsec tunnel management.
git bisect bad 2b02d770c4cb381ec32cd4b7b1e991c42b448884
# first bad commit: [2b02d770c4cb381ec32cd4b7b1e991c42b448884] openvswitch: 
Allow external IPsec tunnel management.
```

The details of the commit
```
2b02d770c4cb381ec32cd4b7b1e991c42b448884 is the first bad commit
commit 2b02d770c4cb381ec32cd4b7b1e991c42b448884
Author: Pravin B Shelar 
Date:   Sat Sep 24 11:44:53 2016 -0700

openvswitch: Allow external IPsec tunnel management.

OVS GRE IPsec tunnel support has multiple issues, Therefore
it was deprecated in OVS 2.6.

Following patch removes support for GRE IPsec and allows external
IPsec tunnel management for any type of tunnel not just GRE.
e.g. user can encrypt Geneve or VxLan traffic.

It can be done by using openflow pipeline to set skb-mark
and using IPsec keying daemons to implement IPsec tunnels.
This packet can be matched for the skb-mark to encrypt
selective tunnel traffic.

VMware-BZ: 1710701
Signed-off-by: Pravin B Shelar 
Acked-by: Ansis Atteka 

:100644 100644 6e284aac32557ba75408375d58546ac7745433dd 
069ab424c644ef0ee992340f450e1dae5fc42454 M  NEWS
:100644 100644 cf5343714937c28b90ca5f3457d23f0ed5df1ebf 
53b0fafe3a56e604c2b62097c54ef6dcd135fe83 M  README.md
:04 04 636109402f0a3a4798d68f9cf85399b7230d7819 
ed14940340a22190843c9270740039e404521b59 M  debian
:04 04 5444eb414d2383ec4340243cbfcfcdb0da80e144 
2c5687e8813086c083ef2df7382a6fc17f782040 M  lib
:04 04 d6cd119e1715c6716dd8fc509169d1499d3a2e31 
310aa4ce502847c2824d4b04bd539e60b2100b26 M  ofproto
:04 04 208fe072c0f3a3f8139f695019c81fcffcfbd373 
6f73eb237766d6bab68fc36389c2ed5fd57e2240 M  tests
:04 04 0c796059e07e889bded911f39324d6e9e3cb6771 
e5ac1d4e6d492899d2194bf451d5393513e5fea1 M  utilities
:04 04 5aa99398dbba68c93985189042fa126bf0c527ed 
aa9d605b55ac9e79524b9151d4173eaccb8eb9d0 M  vswitchd
```

Is it feasible to port this to next release of OvS 2.5.3 ?

>>


Best,
Jesus


-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: 12 September 2017 01:01
To: Llorente Santos Jesus 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] How to submit a bug report

I didn't realize that there was different information on the mailing list and 
in ovs-issues.  Thanks for adding the missing information.

"git bisect" would probably take 10 tries or less to find the commit, so I'd 
still like to encourage you to try that approach.

On Mon, Sep 11, 2017 at 09:27:46PM +, Llorente Santos Jesus wrote:
> Hi Ben, thank 

Re: [ovs-discuss] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

2017-09-19 Thread Darrell Ball


On 9/19/17, 8:22 AM, "Loftus, Ciara"  wrote:

> On 09/19/2017 08:58 AM, Loftus, Ciara wrote:

> >> Thanks for confirming Devendra

> >>

> >> Adding Ciara

> >> There have been some offline discussions regarding the issue.

> >

> > The workaround discussed is a patch to enable backwards compatibility

> with the old port IDs. Something like the following:

> >

> > – set Interface portX options:dpdk-devargs=dpdkportid0

> >

> > Looking for input.

> >

> 

> Seems like a good idea to take in the port number as a workaround. If

> it's just temporary because there will be a fix in DPDK sometime, then

> perhaps a new experimental option could be introduced  (e.g.

> dpdk-legacyname or dpdk-dpdkportnum) and removed in time. Otherwise

> dpdk-devargs usage will be changing between releases, break backwards

> compatibility and probably confuse people migrating from  having two ways to use it.

> 

> Maybe =dpdk0 is better than =dpdkportid0 as it's closer to the old

> behavior you are trying to replicate?

> 

> set Interface mydpdkport options:dpdk-legacyname=dpdk0



I think that's a good approach.


Seems fine to me
One alternative since I remember there was some confusion about the portid 
context before.

dpdk-dpdkportid=dpdk0  ?


> 

> Do you know if the required API will be implemented in DPDK sometime?



There was no response when I cross-posted to DPDK users mailing list, so I 
can't confirm.



Thanks,

Ciara



> 

> > Thanks,

> > Ciara

> >

> >>

> >>

> >> From: devendra rawat 

> >> Date: Monday, September 18, 2017 at 4:27 AM

> >> To: Kevin Traynor 

> >> Cc: Darrel Ball , "ovs-...@openvswitch.org"  >> d...@openvswitch.org>, "disc...@openvswitch.org"

> >> 

> >> Subject: Re: [ovs-dev] adding dpdk ports sharing same pci address to 
ovs-

> >> dpdk bridge

> >>

> >> Hi Kevin,

> >>

> >> On Fri, Sep 8, 2017 at 12:24 AM, Kevin Traynor 

> >> wrote:

> >> On 09/07/2017 06:47 PM, Darrell Ball wrote:

> >>> Adding disc...@openvswitch.org

> >>>

> >>> The related changes went into 2.7

> >>>

> >>>

> >>>

> >>> On 9/7/17, 3:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of

> >> devendra rawat"  >> devendra.rawat.si...@gmail.com> wrote:

> >>>

> >>>  Hi,

> >>>

> >>>  I have compiled and built ovs-dpdk using DPDK v17.08 and OVS 
v2.8.0.

> >> The

> >>>  NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual 
port

> 10G

> >>>  NIC. The problem with this NIC is that it provides only one PCI 
address

> for

> >>>  both the 10G ports.

> >>>

> >>>  So when I am trying to add the two DPDK ports to my br0 bridge

> >>>

> >>>  # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0

> >> type=dpdk

> >>>  options:dpdk-devargs=0002:01:00.0

> >>>

> >>>  # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1

> >> type=dpdk

> >>>  options:dpdk-devargs=0002:01:00.0

> >>>

> >>

> >> Were you able to confirm those addresses by running ./dpdk-devbind.py

> -s

> >> in your /tools dir?

> >>

> >> On running dpdk-devbind.py --status , I can see the ConnectX-3 pro NIC,

> >> having only one PCI address.

> >>

> >> Network devices using DPDK-compatible driver

> >> 

> >> 

> >>

> >> Network devices using kernel driver

> >> ===

> >> 0002:01:00.0 'MT27520 Family [ConnectX-3 Pro] 1007'

> >> if=enP4p1s0d1,enP4p1s0 drv=mlx4_core unused=

> >> 0006:01:00.0 'I210 Gigabit Network Connection 1533' if=enP6p1s0 drv=igb

> >> unused= *Active*

> >>

> >>>  The port dpdk1 is added successfully and able to transfer data, 
but

> adding

> >>>  dpdk0 to br0 fails:

> >>>

> >>>  2017-09-06T14:19:20Z|00045|netdev_dpdk|INFO|Port 0:

> >> e4:1d:2d:4f:78:60

> >>>  2017-09-06T14:19:20Z|00046|bridge|INFO|bridge br0: added

> interface

> >> dpdk1 on

> >>>  port 1


Re: [ovs-discuss] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

2017-09-19 Thread Kevin Traynor
On 09/19/2017 08:58 AM, Loftus, Ciara wrote:
>> Thanks for confirming Devendra
>>
>> Adding Ciara
>> There have been some offline discussions regarding the issue.
> 
> The workaround discussed is a patch to enable backwards compatibility with 
> the old port IDs. Something like the following:
> 
> – set Interface portX options:dpdk-devargs=dpdkportid0
> 
> Looking for input.
> 

Seems like a good idea to take in the port number as a workaround. If
it's just temporary because there will be a fix in DPDK sometime, then
perhaps a new experimental option could be introduced  (e.g.
dpdk-legacyname or dpdk-dpdkportnum) and removed in time. Otherwise
dpdk-devargs usage will be changing between releases, break backwards
compatibility and probably confuse people migrating from  Thanks,
> Ciara
> 
>>
>>
>> From: devendra rawat 
>> Date: Monday, September 18, 2017 at 4:27 AM
>> To: Kevin Traynor 
>> Cc: Darrel Ball , "ovs-...@openvswitch.org" > d...@openvswitch.org>, "disc...@openvswitch.org"
>> 
>> Subject: Re: [ovs-dev] adding dpdk ports sharing same pci address to ovs-
>> dpdk bridge
>>
>> Hi Kevin,
>>
>> On Fri, Sep 8, 2017 at 12:24 AM, Kevin Traynor 
>> wrote:
>> On 09/07/2017 06:47 PM, Darrell Ball wrote:
>>> Adding disc...@openvswitch.org
>>>
>>> The related changes went into 2.7
>>>
>>>
>>>
>>> On 9/7/17, 3:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of
>> devendra rawat" > devendra.rawat.si...@gmail.com> wrote:
>>>
>>>  Hi,
>>>
>>>  I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0.
>> The
>>>  NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port 
>>> 10G
>>>  NIC. The problem with this NIC is that it provides only one PCI 
>>> address for
>>>  both the 10G ports.
>>>
>>>  So when I am trying to add the two DPDK ports to my br0 bridge
>>>
>>>  # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0
>> type=dpdk
>>>  options:dpdk-devargs=0002:01:00.0
>>>
>>>  # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1
>> type=dpdk
>>>  options:dpdk-devargs=0002:01:00.0
>>>
>>
>> Were you able to confirm those addresses by running ./dpdk-devbind.py -s
>> in your /tools dir?
>>
>> On running dpdk-devbind.py --status , I can see the ConnectX-3 pro NIC,
>> having only one PCI address.
>>
>> Network devices using DPDK-compatible driver
>> 
>> 
>>
>> Network devices using kernel driver
>> ===
>> 0002:01:00.0 'MT27520 Family [ConnectX-3 Pro] 1007'
>> if=enP4p1s0d1,enP4p1s0 drv=mlx4_core unused=
>> 0006:01:00.0 'I210 Gigabit Network Connection 1533' if=enP6p1s0 drv=igb
>> unused= *Active*
>>
>>>  The port dpdk1 is added successfully and able to transfer data, but 
>>> adding
>>>  dpdk0 to br0 fails:
>>>
>>>  2017-09-06T14:19:20Z|00045|netdev_dpdk|INFO|Port 0:
>> e4:1d:2d:4f:78:60
>>>  2017-09-06T14:19:20Z|00046|bridge|INFO|bridge br0: added interface
>> dpdk1 on
>>>  port 1
>>>  2017-09-06T14:19:20Z|00047|bridge|INFO|bridge br0: added interface
>> br0 on
>>>  port 65534
>>>  2017-09-06T14:19:20Z|00048|dpif_netlink|WARN|Generic Netlink family
>>>  'ovs_datapath' does not exist. The Open vSwitch kernel module is
>> probably
>>>  not loaded.
>>>  2017-09-06T14:19:20Z|00049|netdev_dpdk|WARN|'dpdk0' is trying to
>> use device
>>>  '0002:01:00.0' which is already in use by 'dpdk1'
>>>  2017-09-06T14:19:20Z|00050|netdev|WARN|dpdk0: could not set
>> configuration
>>>  (Address already in use)
>>>  2017-09-06T14:19:20Z|00051|bridge|INFO|bridge br0: using datapath ID
>>>  e41d2d4f7860
>>>
>>>
>>>  With OVS v2.6.1 I never had this problem as dpdk-devargs was not
>> mandatory
>>>  and just specifying port name was enough to add that port to bridge.
>>>
>>>  Is there a way to add port both ports to bridge ?
>>>
>>>  Thanks,
>>>  Devendra
>>>  ___
>>>  dev mailing list
>>>  d...@openvswitch.org
>>>  https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
>> 2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
>> uZnsw=qO7NdgrrorJhievOguQLmsfEFuBcPfz9NfQX7UME1-
>> 8=ZKHbYlaTjm8VFj6Rggmcb2gw6s3xW4PxEtUy4YFG1VA=
>>>
>>>
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
> 

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


Re: [ovs-discuss] ovs_dpdk: dpdk-socket-mem usage question

2017-09-19 Thread O Mahony, Billy
Hi Wang,

Typically I reserve between 512M and 1G on each Numa.

There is no formula I am aware of for how much memory is actually required.

Fundamentally this will be determined by the maximum number and size of packets 
in-flight at any given time. Which is determined by the ingress packet rate, 
processing time in ovs and the rate and frequency at which egress queues are 
drained.

The maximum memory requiremnt is determined by the number of rx and tx queues 
and how many descriptors each has.  Also longer queues (more descriptors) will 
protect against packet loss up to a point. So QoS/throughput also comes in to 
play. 

On that point dpdkvhostuser ports, as far as I know, current versions of qemu 
have a virtio queue length fixed at compile time so these queue lengths cannot 
be modified by OVS at all.

In short I don't think there is any way other than testing and tuning of the 
dpdk application (in this case OVS) and the particular use case while 
monitoring internal queue usage. This should give you an idea of an acceptable 
maximum length for the various queues and a good first guess as to the total 
amount of memory required.

Regards,
Billy.



> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of ???
> Sent: Wednesday, September 13, 2017 6:35 AM
> To: ovs-...@openvswitch.org; ovs-discuss@openvswitch.org
> Subject: [ovs-dev] ovs_dpdk: dpdk-socket-mem usage question
> 
> Hi All,
> 
> I read below doc, and have one question:
> 
> http://docs.openvswitch.org/en/latest/intro/install/dpdk/
> dpdk-socket-mem
> Comma separated list of memory to pre-allocate from hugepages on specific
> sockets.
> 
> Question:
>OVS+DPDK can let user to specify the needed memory using dpdk-socket-
> mem. But the question is that how to know how much memory is needed. Is
> there some algorithm on how to calculate the memory?Thanks.
> 
> Br,
> Wang Zhike
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

2017-09-19 Thread Flavio Leitner
On Tue, 19 Sep 2017 13:43:25 +0800
Sun Paul  wrote:

> Hi
> 
> below is the output. currently, I am only able to set to use two CPU for PMD.


I was referring to the output of
ovs-vsctl get Open_vSwitch . other_config

fbl

> 
> # ovs-vsctl show
> ea7f2b40-b7b3-4f11-a81f-cf25a56f8172
> Bridge "gtp1"
> Port "dpdk0"
> Interface "dpdk0"
> type: dpdk
> options: {dpdk-devargs=":04:00.2", n_rxq="4"}
> Port "gtp1"
> Interface "gtp1"
> type: internal
> Port "dpdk1"
> Interface "dpdk1"
> type: dpdk
> options: {dpdk-devargs=":04:00.3", n_rxq="4"}
> 
> 
> 
> On Tue, Sep 19, 2017 at 4:09 AM, Flavio Leitner  wrote:
> > On Mon, 18 Sep 2017 16:51:33 +0800
> > Sun Paul  wrote:
> >  
> >> Hi
> >>
> >> I have two interfaces mapped to DPDK, and run the OVS on top of it. I
> >> tried to set the cpu mask, but I cannot only allocate more than 2 CPU
> >> for pmd thread. any idea?
> >>
> >> # /usr/local/bin/ovs-appctl dpif-netdev/pmd-rxq-show
> >> pmd thread numa_id 0 core_id 1:
> >> isolated : false
> >> port: dpdk0 queue-id: 0
> >> pmd thread numa_id 0 core_id 2:
> >> isolated : false
> >> port: dpdk1 queue-id: 0  
> >
> > Could you post the DPDK configuration and what do you want?
> >
> > Thanks,
> > --
> > Flavio
> >  



-- 
Flavio

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


Re: [ovs-discuss] Troubleshooting network issues with ovn without network namespaces

2017-09-19 Thread Daniel Alvarez Sanchez
Hi Vikrant,

Please note that you won't see the metadata namespace getting created
right after creating a network. The namespace will be present only when
necessary; ie., when a port is bound to a chassis and then the metadata
agent
will detect that condition and create/provision the metadata namespace
accordingly *in that chassis*.

So for you to be able to use this namespace for debugging, you would need
a VM running on that node (or bind a port manually to it through the
iface-id
external_id).

Cheers,
Daniel



On Tue, Sep 19, 2017 at 10:06 AM, Numan Siddique 
wrote:

>
> Hi Vikrant,
>
> Please see this link - https://gist.github.com/russ
> ellb/4ab0a9641f12f8ac66fdd6822ee7789e  and grep for "add_phys_port".
>
> Can you see what is the value of "ovn_metadata_enabled" in the file
>  /etc/neutron/plugins/ml2/ml2_conf.ini.
> If it is false, then please change it to true and restart the
> neutron-server. When you create a new network, you should see a metadata
> namespace getting created.
>
>
> Thanks
> Numan
>
>
> On Tue, Sep 19, 2017 at 9:32 AM, Vikrant Aggarwal 
> wrote:
>
>> Thanks for your reply Russell.
>>
>> I installed devstack with latest development releases but I don't see the
>> namespace created with latest version also.
>>
>> ~~~
>>
>> [stack@devstack-centos-controller devstack]$ grep -i ovn local.conf  |
>> grep -v "#"
>> enable_plugin networking-ovn https://git.openstack.org/open
>> stack/networking-ovn
>> enable_service ovn-northd
>> enable_service ovn-controller
>> enable_service networking-ovn-metadata-agent
>>
>> [stack@devstack-centos-controller devstack]$ neutron net-list
>> neutron CLI is deprecated and will be removed in the future. Use
>> openstack CLI instead.
>> +--+---+
>> --+
>> | id   | name  |
>> subnets  |
>> +--+---+
>> --+
>> | 786530e0-775b-482c-8149-c6e751c188da | internal1 |
>> dc4961f7-0be3-46be-a545-da7e3a9add8c 10.10.10.0/24   |
>> | 823cab04-68ea-4d02-843d-ab420e2b0709 | private   |
>> 00893897-44b3-42e6-9b2d-568568fae221 fde5:d829:f076::/64 |
>> |  |   |
>> 10b1f798-729c-4329-ae0a-65946fee80e4 10.0.0.0/26 |
>> | e1ddda3d-eab5-46a9-a880-15f4eab0360c | public|
>> b785fc74-ee29-4d0d-bd1f-234337528024 |
>> |  |   |
>> d49dc742-9709-4e3b-8a45-68333b7af8b1 |
>> +--+---+
>> --+
>>
>> [stack@devstack-centos-controller devstack]$ ip netns list
>> [stack@devstack-centos-controller devstack]$
>> ~~~
>>
>> Can you please share the steps if you have them handy.
>>
>> Thanks & Regards,
>> Vikrant Aggarwal
>>
>>
>> On Tue, Sep 19, 2017 at 1:51 AM, Russell Bryant  wrote:
>>
>>> On Fri, Sep 15, 2017 at 12:45 AM, Vikrant Aggarwal
>>>  wrote:
>>> > Hi Folks,
>>> >
>>> > With ovs as mechanism driver in neutron, I used network namespaces
>>> often to
>>> > troubleshoot the network related issue especially with instances which
>>> are
>>> > not having floating ip attached to them. It's easy to take ssh session
>>> to
>>> > instances without floating ip from network namespace and then take the
>>> > tcpdump at various hops to troubleshoot the issue.
>>> >
>>> > With ovn, hops are reduced as all decisions are made using openflows
>>> but
>>> > it's difficult to troubleshoot the issue.
>>> >
>>> > Do we have any mechanism to take the ssh session to instance with only
>>> > private ip in case of ovn and take tcpdump on logical switches and
>>> ports?
>>>
>>> If you're using the latest Neutron integration (networking-ovn), we
>>> now create namespaces for OpenStack metadata API integration.  You can
>>> use those namespaces like you did before.
>>>
>>> The other option would be to manually create a Neutron port, and then
>>> manually create an interface in a namespace for that Neutron port.  I
>>> can send instructions if needed ...
>>>
>>> --
>>> Russell Bryant
>>>
>>
>>
>> ___
>> 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] Troubleshooting network issues with ovn without network namespaces

2017-09-19 Thread Numan Siddique
Hi Vikrant,

Please see this link -
https://gist.github.com/russellb/4ab0a9641f12f8ac66fdd6822ee7789e  and grep
for "add_phys_port".

Can you see what is the value of "ovn_metadata_enabled" in the file
 /etc/neutron/plugins/ml2/ml2_conf.ini.
If it is false, then please change it to true and restart the
neutron-server. When you create a new network, you should see a metadata
namespace getting created.


Thanks
Numan


On Tue, Sep 19, 2017 at 9:32 AM, Vikrant Aggarwal 
wrote:

> Thanks for your reply Russell.
>
> I installed devstack with latest development releases but I don't see the
> namespace created with latest version also.
>
> ~~~
>
> [stack@devstack-centos-controller devstack]$ grep -i ovn local.conf  |
> grep -v "#"
> enable_plugin networking-ovn https://git.openstack.org/
> openstack/networking-ovn
> enable_service ovn-northd
> enable_service ovn-controller
> enable_service networking-ovn-metadata-agent
>
> [stack@devstack-centos-controller devstack]$ neutron net-list
> neutron CLI is deprecated and will be removed in the future. Use openstack
> CLI instead.
> +--+---+
> --+
> | id   | name  |
> subnets  |
> +--+---+
> --+
> | 786530e0-775b-482c-8149-c6e751c188da | internal1 |
> dc4961f7-0be3-46be-a545-da7e3a9add8c 10.10.10.0/24   |
> | 823cab04-68ea-4d02-843d-ab420e2b0709 | private   |
> 00893897-44b3-42e6-9b2d-568568fae221 fde5:d829:f076::/64 |
> |  |   |
> 10b1f798-729c-4329-ae0a-65946fee80e4 10.0.0.0/26 |
> | e1ddda3d-eab5-46a9-a880-15f4eab0360c | public|
> b785fc74-ee29-4d0d-bd1f-234337528024 |
> |  |   |
> d49dc742-9709-4e3b-8a45-68333b7af8b1 |
> +--+---+
> --+
>
> [stack@devstack-centos-controller devstack]$ ip netns list
> [stack@devstack-centos-controller devstack]$
> ~~~
>
> Can you please share the steps if you have them handy.
>
> Thanks & Regards,
> Vikrant Aggarwal
>
>
> On Tue, Sep 19, 2017 at 1:51 AM, Russell Bryant  wrote:
>
>> On Fri, Sep 15, 2017 at 12:45 AM, Vikrant Aggarwal
>>  wrote:
>> > Hi Folks,
>> >
>> > With ovs as mechanism driver in neutron, I used network namespaces
>> often to
>> > troubleshoot the network related issue especially with instances which
>> are
>> > not having floating ip attached to them. It's easy to take ssh session
>> to
>> > instances without floating ip from network namespace and then take the
>> > tcpdump at various hops to troubleshoot the issue.
>> >
>> > With ovn, hops are reduced as all decisions are made using openflows but
>> > it's difficult to troubleshoot the issue.
>> >
>> > Do we have any mechanism to take the ssh session to instance with only
>> > private ip in case of ovn and take tcpdump on logical switches and
>> ports?
>>
>> If you're using the latest Neutron integration (networking-ovn), we
>> now create namespaces for OpenStack metadata API integration.  You can
>> use those namespaces like you did before.
>>
>> The other option would be to manually create a Neutron port, and then
>> manually create an interface in a namespace for that Neutron port.  I
>> can send instructions if needed ...
>>
>> --
>> Russell Bryant
>>
>
>
> ___
> 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] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

2017-09-19 Thread Loftus, Ciara
> Thanks for confirming Devendra
> 
> Adding Ciara
> There have been some offline discussions regarding the issue.

The workaround discussed is a patch to enable backwards compatibility with the 
old port IDs. Something like the following:

– set Interface portX options:dpdk-devargs=dpdkportid0

Looking for input.

Thanks,
Ciara

> 
> 
> From: devendra rawat 
> Date: Monday, September 18, 2017 at 4:27 AM
> To: Kevin Traynor 
> Cc: Darrel Ball , "ovs-...@openvswitch.org"  d...@openvswitch.org>, "disc...@openvswitch.org"
> 
> Subject: Re: [ovs-dev] adding dpdk ports sharing same pci address to ovs-
> dpdk bridge
> 
> Hi Kevin,
> 
> On Fri, Sep 8, 2017 at 12:24 AM, Kevin Traynor 
> wrote:
> On 09/07/2017 06:47 PM, Darrell Ball wrote:
> > Adding disc...@openvswitch.org
> >
> > The related changes went into 2.7
> >
> >
> >
> > On 9/7/17, 3:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> devendra rawat"  devendra.rawat.si...@gmail.com> wrote:
> >
> >     Hi,
> >
> >     I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0.
> The
> >     NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port 10G
> >     NIC. The problem with this NIC is that it provides only one PCI address 
> >for
> >     both the 10G ports.
> >
> >     So when I am trying to add the two DPDK ports to my br0 bridge
> >
> >     # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0
> type=dpdk
> >     options:dpdk-devargs=0002:01:00.0
> >
> >     # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1
> type=dpdk
> >     options:dpdk-devargs=0002:01:00.0
> >
> 
> Were you able to confirm those addresses by running ./dpdk-devbind.py -s
> in your /tools dir?
> 
> On running dpdk-devbind.py --status , I can see the ConnectX-3 pro NIC,
> having only one PCI address.
> 
> Network devices using DPDK-compatible driver
> 
> 
> 
> Network devices using kernel driver
> ===
> 0002:01:00.0 'MT27520 Family [ConnectX-3 Pro] 1007'
> if=enP4p1s0d1,enP4p1s0 drv=mlx4_core unused=
> 0006:01:00.0 'I210 Gigabit Network Connection 1533' if=enP6p1s0 drv=igb
> unused= *Active*
> 
> >     The port dpdk1 is added successfully and able to transfer data, but 
> >adding
> >     dpdk0 to br0 fails:
> >
> >     2017-09-06T14:19:20Z|00045|netdev_dpdk|INFO|Port 0:
> e4:1d:2d:4f:78:60
> >     2017-09-06T14:19:20Z|00046|bridge|INFO|bridge br0: added interface
> dpdk1 on
> >     port 1
> >     2017-09-06T14:19:20Z|00047|bridge|INFO|bridge br0: added interface
> br0 on
> >     port 65534
> >     2017-09-06T14:19:20Z|00048|dpif_netlink|WARN|Generic Netlink family
> >     'ovs_datapath' does not exist. The Open vSwitch kernel module is
> probably
> >     not loaded.
> >     2017-09-06T14:19:20Z|00049|netdev_dpdk|WARN|'dpdk0' is trying to
> use device
> >     '0002:01:00.0' which is already in use by 'dpdk1'
> >     2017-09-06T14:19:20Z|00050|netdev|WARN|dpdk0: could not set
> configuration
> >     (Address already in use)
> >     2017-09-06T14:19:20Z|00051|bridge|INFO|bridge br0: using datapath ID
> >     e41d2d4f7860
> >
> >
> >     With OVS v2.6.1 I never had this problem as dpdk-devargs was not
> mandatory
> >     and just specifying port name was enough to add that port to bridge.
> >
> >     Is there a way to add port both ports to bridge ?
> >
> >     Thanks,
> >     Devendra
> >     ___
> >     dev mailing list
> >     d...@openvswitch.org
> >     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
> 2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
> uZnsw=qO7NdgrrorJhievOguQLmsfEFuBcPfz9NfQX7UME1-
> 8=ZKHbYlaTjm8VFj6Rggmcb2gw6s3xW4PxEtUy4YFG1VA=
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >

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


Re: [ovs-discuss] DHCP for multiple subnets/VLANs across GRE tunnel using openvswitch patch ports

2017-09-19 Thread Gilbert Standen
Hi actually I solved this myself.  I call the solution to this problem "The 
Lawnmower Man" solution.  The updated solution is here:  
https://sites.google.com/site/nandydandyoracle/openvswitch-ovs/networking-problem-1
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] be free of this mail

2017-09-19 Thread wang zhizhong
Hi, All:

I'm glad to find this group where I can post or discuss questions about ovs.
I'm from china and have worked on network develepment for seven years.
I noticed the ovs two years ago, and now want to know much more about it.
At the same time, I want to make sure if I really joined the discuss group.

Best Regards,
Tsing.Hai

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