Re: [ovs-discuss] The logical of QoS and meter in OVN

[taoyunupt]

Sorry for my terrible expression.


I found  there are two ways to apply QoS in OVN, one is traditional TC, the 
other is meter and meter_band by OVN logical flows.


There are QoS ,meter,meter_band table in OVN.  I do not know the relationships 
among them .And how OVS  do traffic control by meter  and meter_band,when OVN 
has related commands.


best regards,
yunxiang





At 2019-05-29 01:34:29, "Justin Pettit"  wrote:
>I'm not sure I understand the question.  There are many references to meters 
>in the OVS/OVN code in 2.10.
>
>--Justin
>
>
>> On May 22, 2019, at 5:24 PM, taoyunupt  wrote:
>> 
>> Hi,justin,
>> I have confusion about the fulfillment of QoS in OVN（2.10）.  I 
>> can find ‘max_rate’ in options of 'port_binding',and the code goes to method 
>> ‘’setup_qos‘’,which in binding.c
>>  
>>I do not find any code about 'meter',which is the tool of QoSin 
>> OVN/OVS(2.10). So I hope you could give me some explanation of the logical 
>> of QoS in OVN.
>>  
>> 
>> 
>> Best regards,
>> yunxiang
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] LSC does not affect traffic flow

[Dan Sneddon]

Is this a case of confusion between the switch named br0 and an internal
port on the switch named br0? I have found that many people are confused
about that distinction, especially since ovs-vsctl will create the internal
port automatically with the same name as the bridge.

Shutting down the internal port does not shut down the bridge.

In these steps from the original post:

4) sudo ovs-vsctl add-br br0 -- add-port br0 eth0 -- add-port br0
intern-extern -- set interface intern-extern type=internal
5) sudo ip addr flush dev eth0 && sudo dhclient intern-extern
6) sudo ip link set down dev br0


Step 4 creates bridge br0, and ovs-vsctl automatically creates internal
port br0 on the switch, and exposes that port to the OS networking stack as
a device. Step 6 shuts down that internal port, leaving the bridge still
operational. There are use cases for operating a bridge without an internal
interface, especially when using DPDK to avoid sending traffic to the
kernel.

Please correct me if I have any of the above wrong, it's still somewhat
confusing to me too, and I've been working with OVS for a long time.

On Thu, May 2, 2019 at 2:09 PM Ben Pfaff  wrote:

> OK.
>
> The problem here is conceptual.  br0 is just a port on your virtual
> switch.  It isn't along the path of your packet.  It's like
> disconnecting the Ethernet cable from the management port of a physical
> switch: it doesn't disable traffic from flowing through the other ports.
>
> On Thu, May 02, 2019 at 03:49:22PM -0500, Christopher Seeley wrote:
> > I am pinging from another server connected to the same switch. I can ping
> > from inside of an LXC container > br0 > eth0 > physical switch > eth0 (on
> > the other server) > br0 (on the other server) > an LXC container (on the
> > other server). I have done this from both servers and it goes through no
> > matter the state of br0 on either of them.
> >
> > On Thu, May 2, 2019 at 3:32 PM Ben Pfaff  wrote:
> >
> > > Please stop dropping the mailing list.  I don't help off-list.
> > >
> > > On Thu, May 02, 2019 at 03:15:19PM -0500, Christopher Seeley wrote:
> > > > That is the problem. It's not the wrong traffic, just getting traffic
> > > when
> > > > the bridge is supposed to be down. Does an Open-vSwitch ever come
> down?
> > > The
> > > > interface state changes but the bridge state does not.
> > >
> > > You didn't answer my question.  How is the ICMP traffic arriving?  What
> > > command are you running?
> > >
> >
> >
> > --
> > Christopher Seeley
> > Software Developer
> > M: (618) 975-6324
> > [image:
> >
> https://ci4.googleusercontent.com/proxy/N6FGWffGoRzwldCSUGY-TdS5283f1qufOUeSehWDEk0uSdTmwAA_U1NgdVoRvGNVWfWD0QpLQ4RcZ-UwUP30TUtlCy-HzoMxZUua7hmgR_NZwQTVmRIezA=s0-d-e1-ft#http://cybercents.com/assets/img/cybercents_logo_dark-ab5b14ef.png
> ]
> > 1472 North Green Mount Road
> > O'Fallon, IL 62269
>
>
> ___
> 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] Flow Monitoring

[Ashish Varma via discuss]

Please see inline as [Ashish]

On 5/23/19, 8:39 PM, "Ben Pfaff"  wrote:

On Thu, May 23, 2019 at 10:46:40PM -0400, Vasu Dasari wrote:
> Thanks for digging into this. My comments inline. I am sorry that I had to
> differ from your analysis.

Thank you for the correction.  You are right: this is buggy.  OVS does
not and should not claim to support flow monitoring except as an OVS
extension.  I knew that the support was not there before, although I
though we had added it recently, but I did not know that OVS tried
to support it before.

Ashish submitted a patch back in January to add full support:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2019-January%2F355778.html&data=02%7C01%7Cavarma%40vmware.com%7C0fab9e113fa546ca1f6908d6dff9689a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636942659632360052&sdata=NzppkYBtVATlOVD1Ymr8KU7H51o0D2ERfYH9Ll9YtDM%3D&reserved=0
and we discussed it a bit:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2019-February%2F355901.html&data=02%7C01%7Cavarma%40vmware.com%7C0fab9e113fa546ca1f6908d6dff9689a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636942659632360052&sdata=ia8esjGnd7lS9xO6y1HsAOpTBXmsj98u2HWb%2Bf3EvJw%3D&reserved=0
but I do not know of a v3.

Ashish, is there a newer version of this patch?
[Ashish: There was a bug in the related code path which is related to 
'usable_protocol' variable not being set and used properly in the existing code.
I will have the v2 patch for this bug this week and then a v3 for the flow 
monitor as well. The fix for the bug is a pre-requisite for the Flow Monitor v3 
patch. Sorry it took so long.] 

However, for 2.11 and earlier, I expect that the best we can do is to
simply change this request so that it provokes an error.


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

Re: [ovs-discuss] The logical of QoS and meter in OVN

[Justin Pettit]

I'm not sure I understand the question.  There are many references to meters in 
the OVS/OVN code in 2.10.

--Justin


> On May 22, 2019, at 5:24 PM, taoyunupt  wrote:
> 
> Hi,justin,
> I have confusion about the fulfillment of QoS in OVN（2.10）.  I 
> can find ‘max_rate’ in options of 'port_binding',and the code goes to method 
> ‘’setup_qos‘’,which in binding.c
>  
>I do not find any code about 'meter',which is the tool of QoSin 
> OVN/OVS(2.10). So I hope you could give me some explanation of the logical of 
> QoS in OVN.
>  
> 
> 
> Best regards,
> yunxiang

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

Re: [ovs-discuss] ovs datastructure sw_flow_mask

[pei Jikui]

Sorry there is a typo in the original email.

I meant there must be some reasons beyond my understanding and I am eager to 
know the reasons.



发送自 Outlook


发件人: ovs-discuss-boun...@openvswitch.org  
代表 pei Jikui 
发送时间: 2019年5月28日 21:37
收件人: ovs-discuss@openvswitch.org
主题: [ovs-discuss] ovs datastructure sw_flow_mask

hi,

We define the range, begin and end, for  the struct sw_flow_mask.  I am just 
wondering why we don't take use of the bitmap for it?

For example, if we we have an openflow rule which defines the "source mac and 
dstip for some certain actions".
1) based on the 'begin-end' mask design, we need to calculate the hash values 
based on the items from the source mac to the dstip.
2) if we use the bitmap for the mask, we could calculate the hash value only 
based on two items of source mac and dstip.

Comparing with 1), 2) is better for the speed of calculating the hash-value and 
it also saves some memory spaces (only a u32 bitmap is used instead of two u32 
for begin and end)?

I know there are must be some reasons behind my current understanding and glade 
to know them.


Thanks.

Jikui



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

[ovs-discuss] ovs datastructure sw_flow_mask

[pei Jikui]

hi,

We define the range, begin and end, for  the struct sw_flow_mask.  I am just 
wondering why we don't take use of the bitmap for it?

For example, if we we have an openflow rule which defines the "source mac and 
dstip for some certain actions".
1) based on the 'begin-end' mask design, we need to calculate the hash values 
based on the items from the source mac to the dstip.
2) if we use the bitmap for the mask, we could calculate the hash value only 
based on two items of source mac and dstip.

Comparing with 1), 2) is better for the speed of calculating the hash-value and 
it also saves some memory spaces (only a u32 bitmap is used instead of two u32 
for begin and end)?

I know there are must be some reasons behind my current understanding and glade 
to know them.


Thanks.

Jikui



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

[ovs-discuss] OVS-DPDK vhostuserclient ports dropping packets - Ignoring NUMA assignment

[Joan Vidal]

Hi,

I´m trying to use OVS vhostuserclient ports connected to a libvirt guest that 
in turn uses DPDK to manage the interfaces.
When trying to send traffic to the guest OVS is dropping the packets, so far 
the only strange thing I found is incorrect assignment of NUMA PMD threads on 
OVS logs.

OVS interfaces vhost0 and vhost1 connected to a KVM guest. Used  other_config 
to pin PMD threads 10 and 26  on NUMA1 to vhost0 and vhost1 interfaces.

During guest initialization, OVS log shows correct PMD threat assignment to 
NUMA1 but then interfaces are removed and added to the wrong NUMA0

2019-05-27T16:08:11.080Z|00662|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost0' has been added on numa node 1
2019-05-27T16:08:11.081Z|00679|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost1' has been added on numa node 1
2019-05-27T16:10:05.744Z|00737|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost0' has been removed
019-05-27T16:10:06.585Z|00742|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost1' has been removed
2019-05-27T16:10:11.856Z|00775|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost0' has been added on numa node 0
2019-05-27T16:10:11.857Z|00804|netdev_dpdk|INFO|vHost Device 
'/var/run/openvswitch/vhost1' has been added on numa node 0

According to ovs-appctl threads 10 and 26 are the ones assigned to vhost0 and 
vhost1

ovs-appctl dpif-netdev/pmd-rxq-show
pmd thread numa_id 1 core_id 9:
  isolated : true
  port: ens1f0queue-id:  0  pmd usage:  0 %
  port: testdpdk0 queue-id:  0  pmd usage:  0 %
pmd thread numa_id 1 core_id 10:
  isolated : true
  port: vhost0queue-id:  0  pmd usage:  0 %
pmd thread numa_id 1 core_id 25:
  isolated : true
  port: ens1f1queue-id:  0  pmd usage:  0 %
  port: testdpdk1 queue-id:  0  pmd usage:  0 %
pmd thread numa_id 1 core_id 26:
  isolated : true
  port: vhost1queue-id:  0  pmd usage:  0 %

pidstat confirms only NUMA1 has PMD threads:

 pidstat -t -p `pidof ovs-vswitchd` 1 | grep -E pmd\|%CPU
   UID  TGID   TID%usr %system  %guest%CPU   CPU  Command
   995 - 20018  100.000.000.00  100.00 9  |__pmd6
   995 - 20019   99.000.000.00   99.0025  |__pmd7
   995 -  6181  100.000.000.00  100.0026  |__pmd11
   995 -  6183  100.000.000.00  100.0010  |__pmd12
   UID  TGID   TID%usr %system  %guest%CPU   CPU  Command
   995 - 20018  100.001.000.00  100.00 9  |__pmd6
   995 - 20019  100.001.000.00  100.0025  |__pmd7
   995 -  6181  100.000.000.00  100.0026  |__pmd11
   995 -  6183  100.001.000.00  100.0010  |__pmd12


Is this wrong assignment in the logs just a cosmetic issue or could be the root 
cause behind the dropped packets?

--

Software version:

(Tried same setup in 2 KVM hosts running CentOS and Ubuntu got exactly the same 
behaviour in both )

HOST OS: CentOS Linux release 7.6.1810 (Core)
qemu version: 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.7.1)
libvirt version: 4.5.0, package: 10.el7_6.9
ovs-vswitchd (Open vSwitch) 2.11.1
DPDK 18.11.0

HOST OS:  Ubuntu 18.04.2 LTS (Bionic Beaver)
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14)
libvirtd (libvirt) 4.0.0
ovs-vswitchd (Open vSwitch) 2.9.2
DPDK 17.11.2


--

OVS configuration:

ovs-vsctl get Open_vSwitch . other_config:
{dpdk-init="true",  dpdk-socket-mem="0,2048", pmd-cpu-mask="0x06000600"}


ovs-vsctl list interface vhost0
_uuid   : f1a1e95f-2bb9-4760-abfa-47b5786a90f6
admin_state : up
bfd : {}
bfd_status  : {}
cfm_fault   : []
cfm_fault_status: []
cfm_flap_count  : []
cfm_health  : []
cfm_mpid: []
cfm_remote_mpids: []
cfm_remote_opstate  : []
duplex  : []
error   : []
external_ids: {}
ifindex : 6900984
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current: []
link_resets : 0
link_speed  : []
link_state  : up
lldp: {}
mac : []
mac_in_use  : "00:00:00:00:00:00"
mtu : 1500
mtu_request : []
name: "vhost0"
ofport  : 3
ofport_request  : []
options : {n_rxq="1,tag=951", 
vhost-server-path="/var/run/openvswitch/vhost0"}
other_config: {pmd-rxq-affinity="0:10"}
statistics  : {"rx_1024_to_1522_packets"=0, "rx_128_to_255_packets"=0, 
"rx_1523_to_max_packets"=0, "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0, 
"rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0, rx_dropped=0, 
rx_errors=0, rx_packets=0, tx_bytes=0, tx_dropped=25663, tx_packets=0}
status  : {features="0x780067c2", mode=client, 
num_of_vrings="2", numa="1", socket="/var/run/openvswitch/vhost0", 
status=

Re: [ovs-discuss] Reg. ofport set to -1

[Vishal Deep Ajmera]

Hi,

Gentle reminder for folks to share their thoughts. We have a potential fix for 
this issue wherein we do not release the ofport number until the failed port is 
deleted from the ovsdb. Once the failed port is deleted from the ovsdb, the 
ofport number is appended to the LRU list.

Does this make sense ?

Regards,
Vishal

From: Vishal Deep Ajmera
Sent: Tuesday, November 27, 2018 11:17 AM
To: Vishal Deep Ajmera ; 
ovs-discuss@openvswitch.org
Subject: RE: Reg. ofport set to -1

Anyone faced similar issue with other controllers?

From: 
ovs-discuss-boun...@openvswitch.org 
mailto:ovs-discuss-boun...@openvswitch.org>>
 On Behalf Of Vishal Deep Ajmera
Sent: Wednesday, November 21, 2018 2:14 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Reg. ofport set to -1

Hi,

Currently in OVS we set "-1" for ofport field in interface table of OVS DB when 
we fail to initialize the interface. This means if we had allocated any ofport 
number earlier, it is released. When the above failed interface gets 
initialized successfully later it gets a "new" ofport number again. Due to 
change in ofport number, any SDN controller will have to change all the 
openflows corresponding to this interface (due to change in port number). I am 
not sure why we release the ofport number for the interface, unless it is 
deleted from the interface table itself.

Does it make sense to preserve the ofport number as long as the interface is 
present in OVS DB and release it once it is deleted? This will help controller 
not to modify existing flows but only replay (resync) the same, once interface 
comes back alive.

Need some guidance here how to handle such cases.

Warm Regards,
Vishal Ajmera


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