Re: [ovs-discuss] ovsdb-idl APIs to access idl->session and idl->state

2018-08-29 Thread Arunkumar Rg
Thanks Numan. I shall send my patch to dev team.

Regards,
Arun

On Wed, Aug 29, 2018 at 6:33 PM Numan Siddique  wrote:

>
>
> On Wed, Aug 29, 2018 at 1:59 PM Arunkumar Rg 
> wrote:
>
>> Hi,
>>
>> I'm developing a ovsdb-client code using ovsdb-idl.
>> I would need an ovsdb-idl API to access the idl->session and idl->state.
>> So I'm planning to add these APIs in ovs github repo.
>>
>> Currently ovsdb-idl is used as a library in my code. So I can go ahead
>> and add the above required APIs in my local library itself, but the issue
>> is whenever I wanted to pick the latest OVS code then I need to add this
>> APIs in the new OVS version as well.
>>
>> So please let me know whether it is fine to add these APIs in ovs's
>> github repo.
>>
>> Thanks,
>> Arun.
>>
>
> Hi Arun,
>
> Please have a look at this -
> http://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/.
> You can submit your patch to the d...@openvswitch.org.
>
> Thanks
> Numan
>
>
>> ___
>> 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 w dpdk live lock?

2018-08-29 Thread David Evans
Here's what i found

in: ixgbe_ethdev.c line 4000
because:
3995 if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
3996 ixgbe_get_media_type(hw) == ixgbe_media_type_fiber)
this happens:
 ixgbe_setup_link(hw, speed, true); <-- " true" is why we are having to
wait...

This interrupt flag  in the normal case - that we ought to configure the
port... but what if we don't want to just now.
Perhaps DPDK has to change this logic?  AND, Ovs might need to separate the
concerns of the status check from the port setup?


#0  0x7fd08ff790eb in rte_rdtsc () at
/usr/src/debug/dpdk-17.11.3/x86_64-default-linuxapp-gcc/include/rte_cycles.h:75
#1  rte_get_tsc_cycles () at
/usr/src/debug/dpdk-17.11.3/x86_64-default-linuxapp-gcc/include/rte_cycles.h:89
#2  rte_get_timer_cycles () at
/usr/src/debug/dpdk-17.11.3/x86_64-default-linuxapp-gcc/include/generic/rte_cycles.h:128
#3  rte_delay_us_block (us=10) at
/usr/src/debug/dpdk-17.11.3/lib/librte_eal/common/eal_common_timer.c:59
#4  0x7fd08ab60eec in ixgbe_setup_mac_link_multispeed_fiber
(hw=0x7fd03ff8b0c0, speed=128, autoneg_wait_to_complete=1) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/base/ixgbe_common.c:5155
#5  0x7fd08ab86cb4 in ixgbe_dev_link_update_share (vf=0,
wait_to_complete=0, dev=0x7fd08fced400 ) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4000
#6  ixgbe_dev_link_update (dev=0x7fd08fced400 ,
wait_to_complete=0) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4070
#7  0x7fd08fad22ad in rte_eth_link_get_nowait (port_id=,
eth_link=eth_link@entry=0x7ffc224b7200) at
/usr/src/debug/dpdk-17.11.3/lib/librte_ether/rte_ethdev.c:1539
#8  0x55b405791905 in check_link_status (dev=0x7fd03f22dd80) at
lib/netdev-dpdk.c:713
#9  0x55b405791a53 in netdev_dpdk_get_carrier
(netdev=netdev@entry=0x7fd03f22ee00,
carrier=carrier@entry=0x7ffc224b728f) at lib/netdev-dpdk.c:2673
#10 0x55b405791abb in netdev_dpdk_get_stats (netdev=0x7fd03f22ee00,
stats=0x7ffc224b75c0) at lib/netdev-dpdk.c:2406
#11 0x55b4056e0adb in netdev_get_stats (netdev=,
stats=stats@entry=0x7ffc224b75c0) at lib/netdev.c:1416
#12 0x55b40564fca8 in iface_refresh_stats (iface=0x55b405f3bc20) at
vswitchd/bridge.c:2406
#13 0x55b405658d68 in run_stats_update () at vswitchd/bridge.c:2798
#14 bridge_run () at vswitchd/bridge.c:3056
#15 0x55b40564dc9d in main (argc=5, argv=0x7ffc224b7a18) at
vswitchd/ovs-vswitchd.c:119
(gdb) frame 4
#4  0x7fd08ab60eec in ixgbe_setup_mac_link_multispeed_fiber
(hw=0x7fd03ff8b0c0, speed=128, autoneg_wait_to_complete=1) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/base/ixgbe_common.c:5155
5155 msec_delay(100);
(gdb) frame 5
#5  0x7fd08ab86cb4 in ixgbe_dev_link_update_share (vf=0,
wait_to_complete=0, dev=0x7fd08fced400 ) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4000
4000 ixgbe_setup_link(hw, speed, true);
(gdb) info locals
link = 
intr = 0x7fd03ff8bff8
speed = 128
wait = 1
autoneg = 0
hw = 0x7fd03ff8b0c0
old = {link_speed = 0, link_duplex = 0, link_autoneg = 1, link_status = 0}
link_speed = 0
link_up = 100
diag = 
(gdb) frame 6
#6  ixgbe_dev_link_update (dev=0x7fd08fced400 ,
wait_to_complete=0) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4070
4070 return ixgbe_dev_link_update_share(dev, wait_to_complete, 0);
(gdb) info locals
No locals.
(gdb) list
4065 }
4066
4067 static int
4068 ixgbe_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
4069 {
4070 return ixgbe_dev_link_update_share(dev, wait_to_complete, 0);
4071 }
4072
4073 static int
4074 ixgbevf_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
(gdb) frame 7
#7  0x7fd08fad22ad in rte_eth_link_get_nowait (port_id=,
eth_link=eth_link@entry=0x7ffc224b7200) at
/usr/src/debug/dpdk-17.11.3/lib/librte_ether/rte_ethdev.c:1539
1539 (*dev->dev_ops->link_update)(dev, 0);
(gdb) list
1534
1535 if (dev->data->dev_conf.intr_conf.lsc != 0)
1536 rte_eth_dev_atomic_read_link_status(dev, eth_link);
1537 else {
1538 RTE_FUNC_PTR_OR_RET(*dev->dev_ops->link_update);
1539 (*dev->dev_ops->link_update)(dev, 0);
1540 *eth_link = dev->data->dev_link;
1541 }
1542 }
1543
(gdb) frame 5
#5  0x7fd08ab86cb4 in ixgbe_dev_link_update_share (vf=0,
wait_to_complete=0, dev=0x7fd08fced400 ) at
/usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4000
4000 ixgbe_setup_link(hw, speed, true);
(gdb) list
3995 if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
3996 ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
3997 speed = hw->phy.autoneg_advertised;
3998 if (!speed)
3999 ixgbe_get_link_capabilities(hw, , );
4000 ixgbe_setup_link(hw, speed, true);
4001 }
4002
4003 /* check if it needs to wait to complete, if lsc interrupt is enabled
*/
4004 if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)

On Wed, Aug 29, 2018 at 11:10 AM O Mahony, Billy 
wrote:

> Thanks, David. I’ll re-create the scenario here tomorrow and see what
> happens.
>
>
>
> *From:* davidjoshuaev...@gmail.com 

Re: [ovs-discuss] ovs w dpdk live lock?

2018-08-29 Thread O Mahony, Billy
Thanks, David. I’ll re-create the scenario here tomorrow and see what happens.

From: davidjoshuaev...@gmail.com [mailto:davidjoshuaev...@gmail.com]
Sent: Wednesday, August 29, 2018 2:16 PM
To: O Mahony, Billy 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] ovs w dpdk live lock?

Thats correct Billy.

Say for instance you have pings from an internal vPort coming through to a DPDK 
port on a netdev bridge. (an openflow rule for each direction of traffic, no 
mac learning)
Pings work fine till you unplug the other device.
Then traffic will come in bursts and have massive latency up to 3 seconds or 
thereabouts.
Now, from the callback check_link_status down the stack...  
ixgbe_setup_mac_link_multispeed_fiber is 'supposed' to be non-blocking... but i 
see we end up in rte_delay_us_block
And it looks to me that 'main' thread gets hooked up in that activity.

I hope i am not leading you up the garden path, but that seems to me to be 
where it's at.

Dave.






On Wed, Aug 29, 2018 at 7:37 AM O Mahony, Billy 
mailto:billy.o.mah...@intel.com>> wrote:
Hi David,

I just saw this email now. Thanks, that’s interesting.

Can you confirm that the issue is a transient 3s approx. interruption in 
traffic when the cable of another port (not involved in the test traffic) is 
unplugged? Then I will try to recreate it here.

Also I’m re-adding the ovs-discuss list to the cc. “Don’t drop the list” is a 
regular comment on ovs-*.

Regards,
Billy

From: davidjoshuaev...@gmail.com 
[mailto:davidjoshuaev...@gmail.com]
Sent: Tuesday, August 28, 2018 9:07 PM
To: O Mahony, Billy mailto:billy.o.mah...@intel.com>>
Subject: Re: [ovs-discuss] ovs w dpdk live lock?

also...
perhaps related to stats collection

#0  0x7fe86789c0e2 in rte_delay_us_block () from /lib64/librte_eal.so.6
#1  0x7fe8624940c1 in ixgbe_setup_mac_link_multispeed_fiber () from 
/lib64/librte_pmd_ixgbe.so.2
#2  0x7fe8624b5684 in ixgbe_dev_link_update () from 
/lib64/librte_pmd_ixgbe.so.2
#3  0x7fe8673f52ad in rte_eth_link_get_nowait () from 
/lib64/librte_ethdev.so.8
#4  0x560fa8333905 in check_link_status ()
#5  0x560fa8333a53 in netdev_dpdk_get_carrier ()
#6  0x560fa8333abb in netdev_dpdk_get_stats ()
#7  0x560fa8282adb in netdev_get_stats ()
#8  0x560fa81f1ca8 in iface_refresh_stats.part.26 ()
#9  0x560fa81fad68 in bridge_run ()
#10 0x560fa81efc9d in main ()

main thread seems to end up here a lot...


On Mon, Aug 27, 2018 at 11:14 AM David Evans 
mailto:davidjoshuaev...@gmail.com>> wrote:
Hi Billy,
I did some more tests.
It appears to happen when i unplug the optics from the SFP.
The dpdk is 17.11.3 and ovs 2.9.2 source,, but built as RPM's and installed 
from the RPM.
I don't know why the RPM build reports the 17.11.0. - this might be a bug in 
the RPM script.

As you can see from below, i don't even have rules on the switch.
If i add rules to the switch just to force traffic from one port to another, 
there will be traffic interruption.. multiple second latency against the ports.

Start up script looks like this after attach all viable devices to igb_uio

ovsdb-tool create $OVS_DBDIR/conf.db $OVS_SCHEMA
echo "Starting the OVS database server"
ovsdb-server --remote=punix:"$DB_SOCK" \
 --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
 --pidfile --detach

ovs-vsctl --no-wait init

echo ""
echo "start ovs   "
echo ""
echo "Telling the OVS controller to start OVS with DPDK using 512MB hugepage 
memory and run the ovswitchd daemon on logical core 1"
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true \
 other_config:dpdk-lcore-mask=0x1E other_config:dpdk-socket-mem="512"

echo "Starting the OVS daemon..."
ovs-vswitchd unix:$DB_SOCK --pidfile 
--log-file=/var/log/openvswitch/vswitchd.log --detach
sleep 2
echo "Before creating the DPDK ports, tell OVS to use Core 2 for the DPDK PMD"
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x1E
ovs-vsctl add-port br0 dpdkx0 -- set Interface dpdkx0 type=dpdk 
options:dpdk-devargs=:0a:00.0 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx1 -- set Interface dpdkx1 type=dpdk 
options:dpdk-devargs=:0a:00.1 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx2 -- set Interface dpdkx2 type=dpdk 
options:dpdk-devargs=:0b:00.0
ovs-vsctl add-port br0 dpdkx3 -- set Interface dpdkx3 type=dpdk 
options:dpdk-devargs=:0b:00.1

echo "**Clearing current flows"
ovs-ofctl del-flows br0

 You don't need any traffic to get these kind of messages, just un-plug the 
fibre.
2018-08-27T15:41:27.629Z|00483|timeval|WARN|Unreasonably long 2961ms poll 
interval (998ms user, 0ms system)
2018-08-27T15:41:27.629Z|00484|timeval|WARN|context switches: 1 voluntary, 105 
involuntary
2018-08-27T15:41:35.469Z|00485|timeval|WARN|Unreasonably long 2840ms poll 
interval (955ms user, 0ms 

[ovs-discuss] Implementation of HFSC m1 d and m2

2018-08-29 Thread Suprajith HS
Hello guys ,

I am trying to implement m1 , d and m2 in HFSC.  Is there anyone interested
in implementing this feature ?

I need help. Please let me know whom to collaborate with. I will be more
speicific based on what you guys have already done.

Thank you,
Best Regards,
Suprajith HS
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] getting build errors while building ovs2.7.0

2018-08-29 Thread Flavio Leitner
On Wed, Aug 29, 2018 at 11:10:38AM +0800, guoshaoch...@yunrongtech.com wrote:
> hello,
>  Has this problem been solved?
> If it is solved, can you tell me how to do it?
> thans very much!

Can you provide more details about the problem?
It builds fine over here.
-- 
Flavio

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


Re: [ovs-discuss] DPDK vxlan not work

2018-08-29 Thread Lam, Tiago
Hi,

On 28/08/2018 02:38, menkeyi wrote:
> [root@compute01 ~]# uname -r
> 3.10.0-862.el7.x86_64
> 
> 1、Ovs vxlan mode is available
> 2、Ovs + DPDK vxlan mode is not available
> 

Can you provide a bit more info here? What in specific do you see not
working, or not available? And when you say "Ovs vxlan" above (without
DPDK), is that the userspace or the kernel datapath you're referring to?

> DPDK ovs info:
> 
> [root@compute01 ~]# ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.9.0
> DPDK 17.11.0
> 

Just a note that the advised version for using with 2.9.0 is (at least)
DPDK v17.11.2, for security concerns. More info here:
http://mails.dpdk.org/archives/announce/2018-April/000192.html

> [root@compute01 ~]# dpdk-devbind --status|head -n10
> Network devices using DPDK-compatible driver
> 
> :81:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=vfio-pci unused=
> :84:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb'
> drv=vfio-pci unused=
> 
> [root@compute01 ~]# ovs-vsctl show
> b79a7e81-2d68-4ecd-8cd8-bc2b7d1c52ef
> Manager "ptcp:6640:127.0.0.1"
> is_connected: true
> Bridge br-tun
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> Port "vxlan-33000169"
> Interface "vxlan-33000169"
> type: vxlan
> options: {df_default="true", in_key=flow,
> local_ip="51.0.1.101", out_key=flow, remote_ip="51.0.1.105"}
> Port br-tun
> Interface br-tun
> type: internal
> Port "vxlan-330001ca"
> Interface "vxlan-330001ca"
> type: vxlan
> options: {df_default="true", in_key=flow,
> local_ip="51.0.1.101", out_key=flow, remote_ip="51.0.1.202"}
> Bridge br-provider
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port br-provider
> Interface br-provider
> type: internal
> Port phy-br-provider
> Interface phy-br-provider
> type: patch
> options: {peer=int-br-provider}
> Port "Team1"
> Interface "team1-enp132s0f0"
> type: dpdk
> options: {dpdk-devargs=":84:00.0"}
> Interface "team1-enp129s0f0"
> type: dpdk
> options: {dpdk-devargs=":81:00.0"}
> Bridge br-int
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port "vhu15e890ef-36"
> tag: 1
> Interface "vhu15e890ef-36"
> type: dpdkvhostuserclient
> options:
> {vhost-server-path="/var/run/openvswitch/vhu15e890ef-36"}
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port int-br-provider
> Interface int-br-provider
> type: patch
> options: {peer=phy-br-provider}
> Port br-int
> Interface br-int
> type: internal
> Port "vhu82caa59c-d3"
> tag: 1
> Interface "vhu82caa59c-d3"
> type: dpdkvhostuserclient
> options:
> {vhost-server-path="/var/run/openvswitch/vhu82caa59c-d3"}
> Port "tapadb8cafa-a0"
> tag: 4095
> Interface "tapadb8cafa-a0"
> type: internal
> ovs_version: "2.9.0"
> 
> 
> 
> 
> Create a virtual machine and find that the error is found in the
> ovs-vswitchd.log log. I don't know if it is related to this:
> on vxlan_sys_4789 device failed: No such device
> 
>

This shouldn't be related. I'm seeing this on my system as well even
though vxlan is working. It is a bit misleading though, so I'll check
what can lead to this and try to clean it up.

> 
> 2018-08-25T02:34:54.453Z|01178|dpdk|INFO|VHOST_CONFIG: vhost-user
> client: socket created, fd: 83
> 2018-08-25T02:34:54.453Z|01179|netdev_dpdk|INFO|vHost User device
> 'vhu82caa59c-d3' created in 'client' mode, using client socket
> '/var/run/openvswitch/vhu82caa59c-d3'
> 2018-08-25T02:34:54.453Z|01180|dpdk|WARN|VHOST_CONFIG: failed to connect
> to /var/run/openvswitch/vhu82caa59c-d3: No such file or directory
> 2018-08-25T02:34:54.453Z|01181|dpdk|INFO|VHOST_CONFIG:
> /var/run/openvswitch/vhu82caa59c-d3: reconnecting...
> 2018-08-25T02:34:54.634Z|01182|dpif_netdev|INFO|Core 8 on numa node 1
> assigned port 'team1-enp129s0f0' rx queue 0 (measured processing cycles
> 587888).
> 2018-08-25T02:34:54.634Z|01183|dpif_netdev|INFO|Core 8 on numa node 1
> assigned port 'team1-enp132s0f0' rx queue 0 (measured processing cycles
> 402684).
> 

[ovs-discuss] getting build errors while building ovs2.7.0

2018-08-29 Thread guoshaoch...@yunrongtech.com
hello,
 Has this problem been solved?
If it is solved, can you tell me how to do it?
thans very much!



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


Re: [ovs-discuss] ovs w dpdk live lock?

2018-08-29 Thread David Evans
Thats correct Billy.

Say for instance you have pings from an internal vPort coming through to a
DPDK port on a netdev bridge. (an openflow rule for each direction of
traffic, no mac learning)
Pings work fine till you unplug the other device.
Then traffic will come in bursts and have massive latency up to 3 seconds
or thereabouts.
Now, from the callback check_link_status down the stack...
ixgbe_setup_mac_link_multispeed_fiber is 'supposed' to be non-blocking...
but i see we end up in rte_delay_us_block
And it looks to me that 'main' thread gets hooked up in that activity.

I hope i am not leading you up the garden path, but that seems to me to be
where it's at.

Dave.






On Wed, Aug 29, 2018 at 7:37 AM O Mahony, Billy 
wrote:

> Hi David,
>
>
>
> I just saw this email now. Thanks, that’s interesting.
>
>
>
> Can you confirm that the issue is a transient 3s approx. interruption in
> traffic when the cable of another port (not involved in the test traffic)
> is unplugged? Then I will try to recreate it here.
>
>
>
> Also I’m re-adding the ovs-discuss list to the cc. “Don’t drop the list”
> is a regular comment on ovs-*.
>
>
>
> Regards,
>
> Billy
>
>
>
> *From:* davidjoshuaev...@gmail.com [mailto:davidjoshuaev...@gmail.com]
> *Sent:* Tuesday, August 28, 2018 9:07 PM
> *To:* O Mahony, Billy 
> *Subject:* Re: [ovs-discuss] ovs w dpdk live lock?
>
>
>
> also...
>
> perhaps related to stats collection
>
>
>
> #0  0x7fe86789c0e2 in rte_delay_us_block () from /lib64/librte_eal.so.6
>
> #1  0x7fe8624940c1 in ixgbe_setup_mac_link_multispeed_fiber () from
> /lib64/librte_pmd_ixgbe.so.2
>
> #2  0x7fe8624b5684 in ixgbe_dev_link_update () from
> /lib64/librte_pmd_ixgbe.so.2
>
> #3  0x7fe8673f52ad in rte_eth_link_get_nowait () from
> /lib64/librte_ethdev.so.8
>
> #4  0x560fa8333905 in check_link_status ()
>
> #5  0x560fa8333a53 in netdev_dpdk_get_carrier ()
>
> #6  0x560fa8333abb in netdev_dpdk_get_stats ()
>
> #7  0x560fa8282adb in netdev_get_stats ()
>
> #8  0x560fa81f1ca8 in iface_refresh_stats.part.26 ()
>
> #9  0x560fa81fad68 in bridge_run ()
>
> #10 0x560fa81efc9d in main ()
>
>
>
> main thread seems to end up here a lot...
>
>
>
>
>
> On Mon, Aug 27, 2018 at 11:14 AM David Evans 
> wrote:
>
> Hi Billy,
>
> I did some more tests.
>
> It appears to happen when i unplug the optics from the SFP.
>
> The dpdk is 17.11.3 and ovs 2.9.2 source,, but built as RPM's and
> installed from the RPM.
>
> I don't know why the RPM build reports the 17.11.0. - this might be a bug
> in the RPM script.
>
>
>
> As you can see from below, i don't even have rules on the switch.
>
> If i add rules to the switch just to force traffic from one port to
> another, there will be traffic interruption.. multiple second latency
> against the ports.
>
>
>
> Start up script looks like this after attach all viable devices to igb_uio
>
>
>
> ovsdb-tool create $OVS_DBDIR/conf.db $OVS_SCHEMA
>
> echo "Starting the OVS database server"
>
> ovsdb-server --remote=punix:"$DB_SOCK" \
>
>  --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
>
>  --pidfile --detach
>
>
>
> ovs-vsctl --no-wait init
>
>
>
> echo ""
>
> echo "start ovs   "
>
> echo ""
>
> echo "Telling the OVS controller to start OVS with DPDK using 512MB
> hugepage memory and run the ovswitchd daemon on logical core 1"
>
> ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true \
>
>  other_config:dpdk-lcore-mask=0x1E other_config:dpdk-socket-mem="512"
>
>
>
> echo "Starting the OVS daemon..."
>
> ovs-vswitchd unix:$DB_SOCK --pidfile
> --log-file=/var/log/openvswitch/vswitchd.log --detach
>
> sleep 2
>
> echo "Before creating the DPDK ports, tell OVS to use Core 2 for the DPDK
> PMD"
>
> ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x1E
>
> ovs-vsctl add-port br0 dpdkx0 -- set Interface dpdkx0 type=dpdk
> options:dpdk-devargs=:0a:00.0 options:n_rxq=2
>
> ovs-vsctl add-port br0 dpdkx1 -- set Interface dpdkx1 type=dpdk
> options:dpdk-devargs=:0a:00.1 options:n_rxq=2
>
> ovs-vsctl add-port br0 dpdkx2 -- set Interface dpdkx2 type=dpdk
> options:dpdk-devargs=:0b:00.0
>
> ovs-vsctl add-port br0 dpdkx3 -- set Interface dpdkx3 type=dpdk
> options:dpdk-devargs=:0b:00.1
>
>
>
> echo "**Clearing current flows"
>
> ovs-ofctl del-flows br0
>
>
>
>  You don't need any traffic to get these kind of messages, just un-plug
> the fibre.
>
> 2018-08-27T15:41:27.629Z|00483|timeval|WARN|Unreasonably long 2961ms poll
> interval (998ms user, 0ms system)
>
> 2018-08-27T15:41:27.629Z|00484|timeval|WARN|context switches: 1 voluntary,
> 105 involuntary
>
> 2018-08-27T15:41:35.469Z|00485|timeval|WARN|Unreasonably long 2840ms poll
> interval (955ms user, 0ms system)
>
> 2018-08-27T15:41:35.469Z|00486|timeval|WARN|context switches: 1 voluntary,
> 99 involuntary
>
> 

Re: [ovs-discuss] ovsdb-idl APIs to access idl->session and idl->state

2018-08-29 Thread Numan Siddique
On Wed, Aug 29, 2018 at 1:59 PM Arunkumar Rg  wrote:

> Hi,
>
> I'm developing a ovsdb-client code using ovsdb-idl.
> I would need an ovsdb-idl API to access the idl->session and idl->state.
> So I'm planning to add these APIs in ovs github repo.
>
> Currently ovsdb-idl is used as a library in my code. So I can go ahead and
> add the above required APIs in my local library itself, but the issue is
> whenever I wanted to pick the latest OVS code then I need to add this APIs
> in the new OVS version as well.
>
> So please let me know whether it is fine to add these APIs in ovs's github
> repo.
>
> Thanks,
> Arun.
>

Hi Arun,

Please have a look at this -
http://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/.
You can submit your patch to the d...@openvswitch.org.

Thanks
Numan


> ___
> 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 w dpdk live lock?

2018-08-29 Thread O Mahony, Billy
Hi David,

I just saw this email now. Thanks, that’s interesting.

Can you confirm that the issue is a transient 3s approx. interruption in 
traffic when the cable of another port (not involved in the test traffic) is 
unplugged? Then I will try to recreate it here.

Also I’m re-adding the ovs-discuss list to the cc. “Don’t drop the list” is a 
regular comment on ovs-*.

Regards,
Billy

From: davidjoshuaev...@gmail.com [mailto:davidjoshuaev...@gmail.com]
Sent: Tuesday, August 28, 2018 9:07 PM
To: O Mahony, Billy 
Subject: Re: [ovs-discuss] ovs w dpdk live lock?

also...
perhaps related to stats collection

#0  0x7fe86789c0e2 in rte_delay_us_block () from /lib64/librte_eal.so.6
#1  0x7fe8624940c1 in ixgbe_setup_mac_link_multispeed_fiber () from 
/lib64/librte_pmd_ixgbe.so.2
#2  0x7fe8624b5684 in ixgbe_dev_link_update () from 
/lib64/librte_pmd_ixgbe.so.2
#3  0x7fe8673f52ad in rte_eth_link_get_nowait () from 
/lib64/librte_ethdev.so.8
#4  0x560fa8333905 in check_link_status ()
#5  0x560fa8333a53 in netdev_dpdk_get_carrier ()
#6  0x560fa8333abb in netdev_dpdk_get_stats ()
#7  0x560fa8282adb in netdev_get_stats ()
#8  0x560fa81f1ca8 in iface_refresh_stats.part.26 ()
#9  0x560fa81fad68 in bridge_run ()
#10 0x560fa81efc9d in main ()

main thread seems to end up here a lot...


On Mon, Aug 27, 2018 at 11:14 AM David Evans 
mailto:davidjoshuaev...@gmail.com>> wrote:
Hi Billy,
I did some more tests.
It appears to happen when i unplug the optics from the SFP.
The dpdk is 17.11.3 and ovs 2.9.2 source,, but built as RPM's and installed 
from the RPM.
I don't know why the RPM build reports the 17.11.0. - this might be a bug in 
the RPM script.

As you can see from below, i don't even have rules on the switch.
If i add rules to the switch just to force traffic from one port to another, 
there will be traffic interruption.. multiple second latency against the ports.

Start up script looks like this after attach all viable devices to igb_uio

ovsdb-tool create $OVS_DBDIR/conf.db $OVS_SCHEMA
echo "Starting the OVS database server"
ovsdb-server --remote=punix:"$DB_SOCK" \
 --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
 --pidfile --detach

ovs-vsctl --no-wait init

echo ""
echo "start ovs   "
echo ""
echo "Telling the OVS controller to start OVS with DPDK using 512MB hugepage 
memory and run the ovswitchd daemon on logical core 1"
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true \
 other_config:dpdk-lcore-mask=0x1E other_config:dpdk-socket-mem="512"

echo "Starting the OVS daemon..."
ovs-vswitchd unix:$DB_SOCK --pidfile 
--log-file=/var/log/openvswitch/vswitchd.log --detach
sleep 2
echo "Before creating the DPDK ports, tell OVS to use Core 2 for the DPDK PMD"
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x1E
ovs-vsctl add-port br0 dpdkx0 -- set Interface dpdkx0 type=dpdk 
options:dpdk-devargs=:0a:00.0 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx1 -- set Interface dpdkx1 type=dpdk 
options:dpdk-devargs=:0a:00.1 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx2 -- set Interface dpdkx2 type=dpdk 
options:dpdk-devargs=:0b:00.0
ovs-vsctl add-port br0 dpdkx3 -- set Interface dpdkx3 type=dpdk 
options:dpdk-devargs=:0b:00.1

echo "**Clearing current flows"
ovs-ofctl del-flows br0

 You don't need any traffic to get these kind of messages, just un-plug the 
fibre.
2018-08-27T15:41:27.629Z|00483|timeval|WARN|Unreasonably long 2961ms poll 
interval (998ms user, 0ms system)
2018-08-27T15:41:27.629Z|00484|timeval|WARN|context switches: 1 voluntary, 105 
involuntary
2018-08-27T15:41:35.469Z|00485|timeval|WARN|Unreasonably long 2840ms poll 
interval (955ms user, 0ms system)
2018-08-27T15:41:35.469Z|00486|timeval|WARN|context switches: 1 voluntary, 99 
involuntary
2018-08-27T15:41:43.469Z|00487|timeval|WARN|Unreasonably long 3000ms poll 
interval (1000ms user, 0ms system)
2018-08-27T15:41:43.469Z|00488|timeval|WARN|context switches: 1 voluntary, 106 
involuntary
2018-08-27T15:41:51.389Z|00489|timeval|WARN|Unreasonably long 2920ms poll 
interval (996ms user, 0ms system)
2018-08-27T15:41:51.389Z|00490|timeval|WARN|context switches: 1 voluntary, 102 
involuntary
2018-08-27T15:41:58.369Z|00491|timeval|WARN|Unreasonably long 1980ms poll 
interval (992ms user, 0ms system)
2018-08-27T15:41:58.369Z|00492|timeval|WARN|context switches: 0 voluntary, 101 
involuntary
2018-08-27T15:41:58.369Z|00493|coverage|INFO|Dropped 4 log messages in last 31 
seconds (most recently, 7 seconds ago) due to excessive rate
2018-08-27T15:41:58.369Z|00494|coverage|INFO|Event coverage, avg rate over 
last: 5 seconds, last minute, last hour,  hash=dc43467d:
2018-08-27T15:41:58.369Z|00495|coverage|INFO|bridge_reconfigure 0.0/sec 
0.000/sec0.0025/sec   total: 9
2018-08-27T15:41:58.369Z|00496|coverage|INFO|ofproto_flush  0.0/sec 

Re: [ovs-discuss] ovs w dpdk live lock?

2018-08-29 Thread O Mahony, Billy
Hi David,

From: davidjoshuaev...@gmail.com [mailto:davidjoshuaev...@gmail.com]
Sent: Monday, August 27, 2018 5:14 PM
To: O Mahony, Billy 
Subject: Re: [ovs-discuss] ovs w dpdk live lock?

Hi Billy,
I did some more tests.
It appears to happen when i unplug the optics from the SFP.
[[BO'M]] Can you be a little clearer on exactly what happens. You appear to 
have 2 dual port nics configured. What ports are being offered traffic, where 
are you expecting the packets to appear and how are you generating the packets 
how are you detecting if they arrive at the the intended destination or not.
The dpdk is 17.11.3 and ovs 2.9.2 source,, but built as RPM's and installed 
from the RPM.
I don't know why the RPM build reports the 17.11.0. - this might be a bug in 
the RPM script.

As you can see from below, i don't even have rules on the switch.
[[BO'M]] If there are no rules on the switch then no packets should be 
forwarded. If you want the bridge to act like a default l2-learning switch you 
have to explicitly add action=NORMAL to the bridge. Otherwise it appears at 
least on my setup that the any incoming packets will be dropped.
If i add rules to the switch just to force traffic from one port to another, 
there will be traffic interruption.. multiple second latency against the ports.

Start up script looks like this after attach all viable devices to igb_uio

ovsdb-tool create $OVS_DBDIR/conf.db $OVS_SCHEMA
echo "Starting the OVS database server"
ovsdb-server --remote=punix:"$DB_SOCK" \
 --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
 --pidfile --detach

ovs-vsctl --no-wait init

echo ""
echo "start ovs   "
echo ""
echo "Telling the OVS controller to start OVS with DPDK using 512MB hugepage 
memory and run the ovswitchd daemon on logical core 1"
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true \
 other_config:dpdk-lcore-mask=0x1E other_config:dpdk-socket-mem="512"

echo "Starting the OVS daemon..."
ovs-vswitchd unix:$DB_SOCK --pidfile 
--log-file=/var/log/openvswitch/vswitchd.log --detach
sleep 2
echo "Before creating the DPDK ports, tell OVS to use Core 2 for the DPDK PMD"
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x1E
ovs-vsctl add-port br0 dpdkx0 -- set Interface dpdkx0 type=dpdk 
options:dpdk-devargs=:0a:00.0 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx1 -- set Interface dpdkx1 type=dpdk 
options:dpdk-devargs=:0a:00.1 options:n_rxq=2
ovs-vsctl add-port br0 dpdkx2 -- set Interface dpdkx2 type=dpdk 
options:dpdk-devargs=:0b:00.0
ovs-vsctl add-port br0 dpdkx3 -- set Interface dpdkx3 type=dpdk 
options:dpdk-devargs=:0b:00.1

[[BO'M]] You shouldn’t have overlap between the lcore mask and the pmd-mask. 
Although I can’t see that causing anything like your issue change them to not 
overlap.

echo "**Clearing current flows"
ovs-ofctl del-flows br0

 You don't need any traffic to get these kind of messages, just un-plug the 
fibre.
2018-08-27T15:41:27.629Z|00483|timeval|WARN|Unreasonably long 2961ms poll 
interval (998ms user, 0ms system)
2018-08-27T15:41:27.629Z|00484|timeval|WARN|context switches: 1 voluntary, 105 
involuntary
2018-08-27T15:41:35.469Z|00485|timeval|WARN|Unreasonably long 2840ms poll 
interval (955ms user, 0ms system)
2018-08-27T15:41:35.469Z|00486|timeval|WARN|context switches: 1 voluntary, 99 
involuntary
2018-08-27T15:41:43.469Z|00487|timeval|WARN|Unreasonably long 3000ms poll 
interval (1000ms user, 0ms system)
2018-08-27T15:41:43.469Z|00488|timeval|WARN|context switches: 1 voluntary, 106 
involuntary
2018-08-27T15:41:51.389Z|00489|timeval|WARN|Unreasonably long 2920ms poll 
interval (996ms user, 0ms system)
2018-08-27T15:41:51.389Z|00490|timeval|WARN|context switches: 1 voluntary, 102 
involuntary
2018-08-27T15:41:58.369Z|00491|timeval|WARN|Unreasonably long 1980ms poll 
interval (992ms user, 0ms system)
2018-08-27T15:41:58.369Z|00492|timeval|WARN|context switches: 0 voluntary, 101 
involuntary
2018-08-27T15:41:58.369Z|00493|coverage|INFO|Dropped 4 log messages in last 31 
seconds (most recently, 7 seconds ago) due to excessive rate
2018-08-27T15:41:58.369Z|00494|coverage|INFO|Event coverage, avg rate over 
last: 5 seconds, last minute, last hour,  hash=dc43467d:
2018-08-27T15:41:58.369Z|00495|coverage|INFO|bridge_reconfigure 0.0/sec 
0.000/sec0.0025/sec   total: 9
2018-08-27T15:41:58.369Z|00496|coverage|INFO|ofproto_flush  0.0/sec 
0.000/sec0.0003/sec   total: 1
2018-08-27T15:41:58.369Z|00497|coverage|INFO|ofproto_recv_openflow  0.0/sec 
0.000/sec0.0008/sec   total: 6
2018-08-27T15:41:58.369Z|00498|coverage|INFO|ofproto_update_port0.0/sec 
0.033/sec0.0036/sec   total: 13
2018-08-27T15:41:58.369Z|00499|coverage|INFO|rev_reconfigure0.0/sec 
0.000/sec0.0028/sec   total: 10

[ovs-discuss] ovsdb-idl APIs to access idl->session and idl->state

2018-08-29 Thread Arunkumar Rg
Hi,

I'm developing a ovsdb-client code using ovsdb-idl.
I would need an ovsdb-idl API to access the idl->session and idl->state. So
I'm planning to add these APIs in ovs github repo.

Currently ovsdb-idl is used as a library in my code. So I can go ahead and
add the above required APIs in my local library itself, but the issue is
whenever I wanted to pick the latest OVS code then I need to add this APIs
in the new OVS version as well.

So please let me know whether it is fine to add these APIs in ovs's github
repo.

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