[ovs-discuss] Is it possible to create ovs-bridge without MAC address ?

[John Mok]

Hi,

I am using openvswitch 2.3.0 (on Debian 8) to create VLAN(s) and
bridges for Xen VM use. When I connect my computer to office network
which has "sticky" bit set, the switch detects multiple MAC addresses
(ovs-bridge + physical ethernet) on one port and blocked my access.

Is it possible to create ovs-bridge without MAC address, just like
physical L2 switch ?

Thanks a lot.

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

Re: [ovs-discuss] ovs-dpdk performance not stable

[michael me]

Hi Ian,

Thank you for you answers!

it is correct that i am using ovs-vsctl set Interface dpdk0 options:n_rxq=8
commands for the queues.
Could you please expand on the sentence "  It will be split between queues
based on des tip so it’s important that test traffic varies if you want
traffic to be dispersed evenly among the queues at this level."
It might be a typo, or i might just not know what you mean by "des tip",
could you please clarify for me?
Additionally, what do you mean by varying the traffic? do you mean to
somehow not have the packets at a constant frame rate?

Regarding the Vhost user queues, i am using Openstack and i did not find
yet a way to create multiple queues (i updated the image's
metadata hw_vif_multiqueue_enabled=true) but i don't know how to set the
queue amount especially that in the VM that i am running i do not have
ethtool.

Regarding the multiple queues while using one core for the PMD:
i did get much better performance when i had two cores for the PMD,
however, i am not at the luxury to be able to use two cores.
It is puzzling for me that when i use multiple queues i do get better
performance not enough but much better then when i use only one.
I am sorry but this is a confusing for me.

As for the core isolation, i have only core zero isolated for the kernel. i
checked with htop and i saw that probably the emulatorpin of the VM might
be running there so i moved it but it decreased performance.
when i use only n_rxq and n_txq=1 i get performance close to 60MB with 64
packets.

Thank you again,
Michael





On Thu, Apr 19, 2018 at 11:10 AM, Stokes, Ian  wrote:

> Hi Michael,
>
>
>
> So there are a few issues here we need to address.
>
>
>
> Queues for phy devices:
>
>
>
> I assume you have set the queues for dpdk0 and dpdk1 yourself using
>
>
>
> ovs-vsctl set Interface dpdk0 options:n_rxq=8
>
> ovs-vsctl set Interface dpdk0 options:n_rxq=8
>
>
>
> Receive Side Scaling (RSS) is used to distribute ingress traffic among the
> queues on the NIC at a hardware level. It will be split between queues
> based on des tip so it’s important that test traffic varies if you want
> traffic to be dispersed evenly among the queues at this level.
>
>
>
> Vhost user queues:
>
>
>
> You do not have to set the number of queues for vhost ports with n_rxq
> since OVS 2.6 as done above but you do have to include the number of
> supported queues in the QEMU command line argument that launches the VM by
> specifying the argument queues=’Num_Queues’ for the vhost port. If using VM
> Kernel virtio interfaces within the VM you will need to enable the extra
> queues also using ethtool –L. Seeing that there is only 1 queue for your
> vhost user port I think you are missing one of these steps.
>
>
>
> PMD configuration:
>
>
>
> Since your only using 1 PMD I don’t see much point of using multiple
> queues. Typically you match the number of PMDs to the number of queues that
> you would like to ensure an even distribution.
>
> If  using 1 PMD like in your case the traffic will always be enqueued to
> queue 0 of vhost device even if there are multiple queues available. This
> is related to the implantation within OVS.
>
>
>
> As a starting point it might be easier to start with 2 PMDs and 2 rxqs for
> each phy and vhost ports that you have and ensure that works first.
>
>
>
> Also are you isolating the cores the PMD runs on? If not then processes
> could be scheduled to that core which would interrupt the PMD processing,
> this could be related to the traffic drops you see.
>
>
>
> Below is a link to a blog that discusses vhost MQ, it uses OVS 2.5 but a
> lot of the core concepts still apply even if some of the configuration
> commands may have changed
>
>
>
> https://software.intel.com/en-us/articles/configure-vhost-
> user-multiqueue-for-ovs-with-dpdk
>
>
>
> Ian
>
>
>
> *From:* michael me [mailto:1michaelmesgu...@gmail.com]
> *Sent:* Wednesday, April 18, 2018 2:23 PM
> *To:* Stokes, Ian 
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] ovs-dpdk performance not stable
>
>
>
> Hi Ian,
>
>
>
> In the deployment i do have vhost user; below is the full output of the  
> ovs-appctl
> dpif-netdev/pmd-rxq-show  command.
>
> root@W:/# ovs-appctl dpif-netdev/pmd-rxq-show
>
> pmd thread numa_id 0 core_id 1:
>
> isolated : false
>
> port: dpdk1 queue-id: 0 1 2 3 4 5 6 7
>
> port: dpdk0 queue-id: 0 1 2 3 4 5 6 7
>
> port: vhu1cbd23fd-82queue-id: 0
>
> port: vhu018b3f01-39queue-id: 0
>
>
>
> what is strange for me and i don't understand is why do i have only one
> queue in the vhost side and eight on the dpdk side. i understood that qemue
> automatically had the same amount. though, i am using only one core for the
> VM and one core for the PMD.
>
> in this setting i have eight cores in the system, is that the reason that
> i see eight possible queues?
>
> The setup is North/South (VM to Physical 

[ovs-discuss] Could be a bug: extremely long latency for ovn-controller to get SB update in scale test

[Han Zhou]

While working on ovn-controller incremental processing, I was testing the
end-to-end latency and comparing with master. I found the latency with
master branch is extremely long while changing the way of testing makes it
much shorter. The master branch was at commit 593e93e5f (ovsdb clustering
was not merged yet). I promised in last ovn meeting to send a report and
here are the details.

*Precondition: *
there are 1k sandbox HVs connected, and 10k lports already created and
bound on these HVs. There are 8 lrouters, each connected with 5 lswitches,
and each lswitch has 250 lports.

*Test: *
- on a sandbox (HV1), create a ovs-port:
# ovs-vsctl add-port br-int lsp1 -- set interface lsp1 type=internal -- set
interface lsp1 external-ids:iface-id=lsp1

- create the lport on NB on a lswitch that is not yet in local datapath of
HV1, wait for port up and then sync HVs
# time ovn-nbctl lsp-add lswitch_b9322b_ecpmKt lsp1 -- lsp-set-addresses
lsp1 "aa:aa:aa:aa:aa:aa 172.145.222.222"; time ovn-nbctl wait-until
Logical_Switch_Port lsp1 up=true; time ovn-nbctl --wait=hv sync

*Result:*
real0m0.408s
user0m0.316s
sys 0m0.008s

real0m4.837s
user0m0.348s
sys 0m0.012s

*real7m48.373s*
user0m0.348s
sys 0m0.016s

*Notes: *

- the time for the last --wait=hv sync is extremely long: 7m48s.

- the test is with the patch for nb_cfg separation (
https://patchwork.ozlabs.org/patch/899608/), so that --wait=hv sync is
optimized without notification flooding.

- the lswitch where the lsp1 is added doesn't belong to any existing local
datapath on HV1, i.e., there is no other existing lport on HV1 in this
lswitch or any other lswitch that is connected with this lswitch by the
same lrouter. This means when adding the lport the HV1 will change monitor
condition to watch on a new set of datapaths and port-bindings on them.
 (tested with adding the lsp1 on an existing local datapath, there is no
such extremely long latency.)

- adding a command to sync hvs before waiting for port up changes the
behavior: the total latency is only 20+ seconds then:
 # time ovn-nbctl lsp-add lswitch_b9322b_ecpmKt lsp1 --
lsp-set-addresses lsp1 "aa:aa:aa:aa:aa:aa 172.145.222.222"; *time ovn-nbctl
--wait=hv sync;* time ovn-nbctl wait-until Logical_Switch_Port lsp1
up=true; time ovn-nbctl --wait=hv sync

*Debug log analysis:*

With debug log enabled for ovn-controller, I found that the latency was
because ovn-controller didn't get any SB update during the 7+ minutes. Here
are the related logs and analysis:

// HV1 got notification of lsp1 port binding added by northd after the lsp1
is created in NB
2018-03-20T00:00:07.353Z|51461|jsonrpc|DBG|tcp:192.168.10.10:6640: received
notification, method="update2",
params=["monid",{"Port_Binding":{"d6f145bf-ac8f-4107-a565-9ef1fcc9ec6c":{"insert":{"tunnel_key":252,"mac":"aa:aa:aa:aa:aa:aa
172.145.222.222","logical_port":"lsp1","datapath":["uuid","bb979633-789e-4ef8-9663-51839f000c0f"]]


// Claim the lsp1 on this chassis
2018-03-20T00:00:07.367Z|51465|binding|INFO|Claiming lport lsp1 for this
chassis.
2018-03-20T00:00:07.367Z|51466|binding|INFO|lsp1: Claiming
aa:aa:aa:aa:aa:aa 172.145.222.222

// Update port binding to this chassis
2018-03-20T00:00:11.381Z|51588|jsonrpc|DBG|tcp:192.168.10.10:6640: send
request, method="transact",
params=["OVN_Southbound",{"where":[["_uuid","==",["uuid","d6f145bf-ac8f-4107-a565-9ef1fcc9ec6c"]]],"row":{"chassis":["uuid","b2f297f6-cd8b-4429-94f0-274a24d6640a"]},"op":"update","table":"Port_Binding"}],
id=*2169*

// Send request to change monitor conditions for new local datapaths
2018-03-20T00:00:11.382Z|51594|jsonrpc|DBG|tcp:192.168.10.10:6640: send
request, method=“monitor_cond_change” … id=*2170*

// Received notification for its own port-binding update
2018-03-20T00:00:11.383Z|51595|jsonrpc|DBG|tcp:192.168.10.10:6640: received
notification, method="update2",
params=["monid",{"Port_Binding":{"d6f145bf-ac8f-4107-a565-9ef1fcc9ec6c":{"modify":{"chassis":["uuid","b2f297f6-cd8b-4429-94f0-274a24d6640a"]]

2018-03-20T00:00:11.383Z|51596|jsonrpc|DBG|tcp:192.168.10.10:6640: received
reply, result=[{"count":1}], id=*2169*

*/ 7 minutes later ... but why???*

// Received the notification for the new monitor condition related data
(it's huge data)
2018-03-20T00:07:56.183Z|52643|jsonrpc|DBG|tcp:192.168.10.10:6640: received
notification, method="update2",
params=["monid",{"Multicast_Group":{"944391c4-7bf9-4d46-9662-966f9a5450e0":{"insert":{"ports":["set",[["uuid","00d22282-ac38-4a4e-8f47-3684fa915051"],["uuid","03010cdb-647b-4a1d-b0ca-7f4b0e7a6862"],["uuid","03ba954f-5c96-47f0-b517-4f30b2e61907"],["uuid","0480cf96-5158-45aa-ba49-6053cdec5ce3"],["uuid","052397f5-ebb3-4e81-9970-...(huge
data)...

2018-03-20T00:07:56.386Z|52644|jsonrpc|DBG|tcp:192.168.10.10:6640: received
reply, result={}, id=

*2170*
// Received the nb_cfg change triggered by the --wait=hv sync command,
together with the lflow update caused by the port status change: up=true

[ovs-discuss] latest OVS-2.9.0 Build

[Mahesh Loni via discuss]

OVS team,

 

We are working on opendaylight CSIT. Currently we are using OVS-2.9.0
version and their was an issue and got fixed on March- 9- 2018.

 



 

 

If you have triggered latest OVS-2.9.x Build after March 9 . Please let us
know the path to download since we need only release Build for our testing
for example :   http://openvswitch.org/releases/openvswitch-2.9.0.tar.gz

If not please let us know when its going to be available . Its helps us to
proceed further on  blocked testing.

 

BRs,

Mahesh Loni

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Vishal Deep Ajmera]

> Zak is working on that feature; I expect patches will hit the mailing list in 
> the next week or two.

Hi Justin,

As part of this feature, will it also enable us to rewrite the options tlv:type 
field from SLL (1) to TLL (2) Or may be a set-field option to rewrite these 
fields in Options TLV. This will help in supporting multicast solicitations.

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

Re: [ovs-discuss] ovs-dpdk performance not stable

[Stokes, Ian]

Hi Michael,

So there are a few issues here we need to address.

Queues for phy devices:

I assume you have set the queues for dpdk0 and dpdk1 yourself using

ovs-vsctl set Interface dpdk0 options:n_rxq=8
ovs-vsctl set Interface dpdk0 options:n_rxq=8

Receive Side Scaling (RSS) is used to distribute ingress traffic among the 
queues on the NIC at a hardware level. It will be split between queues based on 
des tip so it’s important that test traffic varies if you want traffic to be 
dispersed evenly among the queues at this level.

Vhost user queues:

You do not have to set the number of queues for vhost ports with n_rxq since 
OVS 2.6 as done above but you do have to include the number of supported queues 
in the QEMU command line argument that launches the VM by specifying the 
argument queues=’Num_Queues’ for the vhost port. If using VM Kernel virtio 
interfaces within the VM you will need to enable the extra queues also using 
ethtool –L. Seeing that there is only 1 queue for your vhost user port I think 
you are missing one of these steps.

PMD configuration:

Since your only using 1 PMD I don’t see much point of using multiple queues. 
Typically you match the number of PMDs to the number of queues that you would 
like to ensure an even distribution.
If  using 1 PMD like in your case the traffic will always be enqueued to queue 
0 of vhost device even if there are multiple queues available. This is related 
to the implantation within OVS.

As a starting point it might be easier to start with 2 PMDs and 2 rxqs for each 
phy and vhost ports that you have and ensure that works first.

Also are you isolating the cores the PMD runs on? If not then processes could 
be scheduled to that core which would interrupt the PMD processing, this could 
be related to the traffic drops you see.

Below is a link to a blog that discusses vhost MQ, it uses OVS 2.5 but a lot of 
the core concepts still apply even if some of the configuration commands may 
have changed

https://software.intel.com/en-us/articles/configure-vhost-user-multiqueue-for-ovs-with-dpdk

Ian

From: michael me [mailto:1michaelmesgu...@gmail.com]
Sent: Wednesday, April 18, 2018 2:23 PM
To: Stokes, Ian 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] ovs-dpdk performance not stable

Hi Ian,

In the deployment i do have vhost user; below is the full output of the  
ovs-appctl dpif-netdev/pmd-rxq-show  command.
root@W:/# ovs-appctl dpif-netdev/pmd-rxq-show
pmd thread numa_id 0 core_id 1:
isolated : false
port: dpdk1 queue-id: 0 1 2 3 4 5 6 7
port: dpdk0 queue-id: 0 1 2 3 4 5 6 7
port: vhu1cbd23fd-82queue-id: 0
port: vhu018b3f01-39queue-id: 0

what is strange for me and i don't understand is why do i have only one queue 
in the vhost side and eight on the dpdk side. i understood that qemue 
automatically had the same amount. though, i am using only one core for the VM 
and one core for the PMD.
in this setting i have eight cores in the system, is that the reason that i see 
eight possible queues?
The setup is North/South (VM to Physical network)
as for pinning the PMD, i always pin the PMD to core 1 (mask=0x2).

when i set the n_rxq and n_txq to high values (even 64 or above) i see no drops 
for around a minute or two and then suddenly bursts of drops as if the cache 
was filled. Have you seen something similar?
i tried to play with the "max-idle", but it didn't seem to help.

originally, i had a setup with 2.9 and 17.11 and i was not able to get better, 
performance but it could be that i didn't tweak as much. However, i am trying 
to deploy a setup that i can install without needing to MAKE.

Thank you for any input,
Michael

On Tue, Apr 17, 2018 at 6:28 PM, Stokes, Ian 
> wrote:
Hi Michael,

Are you using dpdk vhostuser ports in this deployment?

I would expect to see them listed in the output of ovs-appctl 
dpif-netdev/pmd-rxq-show you posted below.

Can you describe the expected traffic flow ( Is it North/South using DPDK phy 
devices as well as vhost devices or east/west between vm interfaces only).

OVS 2.6 has the ability to isolate and pin rxq queues for dpdk devices to 
specific PMDs also. This can help provide more stable throughput and defined 
behavior. Without doing this I believe the distribution of rxqs was dealt with 
in a round robin manner which could change between deployments. This could 
explain what you are seeing i.e. sometimes the traffic runs without drops.

You could try to examine ovs-appctl dpif-netdev/pmd-rxq-show when traffic is 
dropping and then again when traffic is passing without issue. This output 
along with the flows in each case might provide a clue as to what is happening. 
If there is a difference between the two you could investigate pinning the rxqs 
to the specific setup although you will only benefit from this when have at 
least 2 PMDs instead of 1.

Also OVS 2.6 and DPDK