Re: [ovs-discuss] OFPACT_DEC_TTL in kernel space

[Justin Pettit]

We try to implement the minimum interface that we can in the kernel.  Usually 
the TTL doesn't change across a flow, so matching on a particular TTL value and 
setting a new value isn't a problem.  Plus, it allows us flexibility to stack 
multiple OpenFlow decrements (useful for logical routers, for example) to 
become a single modify action in the kernel.

Is there a particular use-case that requires decrement?

--Justin


> On Jun 24, 2019, at 5:06 PM, Sagar A  wrote:
> 
> Hello,
> 
> I see that there is an action OFPACT_DEC_TTL in user space, but not in kernel 
> space for OVS. Is there a reason why kernel space action is not implemented? 
> If one has to implement the kernel space action OFPACT_DEC_TTL, what will be 
> the approach? The reason I want to have kernel space action OFPACT_DEC_TTL is 
> that to avoid 'ttl' as the match condition in flow.
> 
> Thank you.
> ___
> 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

[ovs-discuss] OFPACT_DEC_TTL in kernel space

[Sagar A]

Hello,

I see that there is an action OFPACT_DEC_TTL in user space, but not in
kernel space for OVS. Is there a reason why kernel space action is not
implemented? If one has to implement the kernel space action
OFPACT_DEC_TTL, what will be the approach? The reason I want to have kernel
space action OFPACT_DEC_TTL is that to avoid 'ttl' as the match condition
in flow.

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

Re: [ovs-discuss] TSO changes with OVS-DPDK for higher throughput

[Ian Stokes]

On 6/24/2019 1:03 PM, Murali Veluru wrote:

Hi All,

I am testing ovs-dpdk performance test with the help of IPERF.

I created VM using qemu command.

I assigned IP 10.0.1.16 to VM and other device IP is 10.0.1.18 (Dev2). I 
am able to ping and able to run IPERF.


It is giving average output ~3.5G form VM to DEV2 on 10G physical 
interface. form DEV2 to VM it is 5.7G throughput.


I used below version.

DPDK: dpdk-18.11.1.tar.xz

OVS: openvswitch-2.11.1

 From Intel document I found TSO changes but it was for 2.6 version. 
somehow I managed to apply on openvswitch-2.11.1 file.


With TSO disable I am able to do ssh other IP address of DEV2. After 
enable TSO with the help of qemu command IPERF and SSH is getting hanged.


https://mail.openvswitch.org/pipermail/ovs-dev/2018-August/350834.html

Is openvswitch-2.11.1 supports TSO enable by default?


Hi,

TSO is not available in OVS 2.11. There were patches submitted for that 
release but unfortunately it did not make it upstream due to some 
regression performance concerns for non TSO usecases. Intel is currently 
planning to review rework the patchset to address the issues and will be 
releasing a new patchset in the coming months.


In the mean time if you wish to test TSO with the previous patchset that 
was available you can follow the mails and patches outlined in the 
following link (it was related to a similar question)


https://mail.openvswitch.org/pipermail/ovs-discuss/2019-May/048671.html

It's complete with documentation on setup and usage so should be able to 
get you going.


Regards
Ian


Is any patch availble for openvswitch-2.11.1 for TSO changes?

Is qemu related changes are required for TSO enable?

I used below changes using qemu command.

csum=on,gso=on,host_tso4=on,host_tso6=on,host_ecn=on,host_ufo=on,guest_tso4=on,guest_csum=on,guest_tso6=on,guest_ecn=on,guest_ufo=on

Thaks lot.

Regards

Murali


___
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

[ovs-discuss] TSO changes with OVS-DPDK for higher throughput

[Murali Veluru]

Hi All,
I am testing ovs-dpdk performance test with the help of IPERF.

I created VM using qemu command.
I assigned IP 10.0.1.16 to VM and other device IP is 10.0.1.18 (Dev2). I am 
able to ping and able to run IPERF.
It is giving average output ~3.5G form VM to DEV2 on 10G physical interface. 
form DEV2 to VM it is 5.7G throughput.

I used below version.

DPDK: dpdk-18.11.1.tar.xz
OVS: openvswitch-2.11.1

>From Intel document I found TSO changes but it was for 2.6 version. somehow I 
>managed to apply on openvswitch-2.11.1 file.

With TSO disable I am able to do ssh other IP address of DEV2. After enable TSO 
with the help of qemu command IPERF and SSH is getting hanged.

https://mail.openvswitch.org/pipermail/ovs-dev/2018-August/350834.html

Is openvswitch-2.11.1 supports TSO enable by default?
Is any patch availble for openvswitch-2.11.1 for TSO changes?
Is qemu related changes are required for TSO enable?

I used below changes using qemu command.

csum=on,gso=on,host_tso4=on,host_tso6=on,host_ecn=on,host_ufo=on,guest_tso4=on,guest_csum=on,guest_tso6=on,guest_ecn=on,guest_ufo=on

Thaks lot.

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

[ovs-discuss] OVS + VXLAN Performance

[Heim, Dennis]

I am running Ubuntu on virtualized hosts, along with VXLAN. However, the VXLAN 
performance has been poor. I am trying to verify the VM environment. Any 
recommendations from a performance tuning perspective? Is it possible to get 
good performance with VXLAN in virtual hardware, or would I be better going 
with a different tunnel type.

Thanks,

Dennis Heim | Domain Architect (Collaboration Labs)
World Wide Technology, Inc. | +1 314-212-1814
[cid:image001.png@01D10DD2.7FC81F90]
[cid:image002.png@01D10DD2.7FC81F90][cid:image003.png@01D10DD2.7FC81F90][cid:image004.png@01D10DD2.7FC81F90]
"The most powerful person in the world is the story teller. The storyteller 
sets the vision, values and agenda of an entire generation that is to come" - 
Steve Jobs
"Leaders who don't listen will eventually be surrounded by people who have 
nothing to say" --- Andy Stanley
"Worry less about who you might offend, and more about who you might inspire" 
-- Tim Allen
"Imagination is more important than knowledge."  -- Albert Einstein
"If you can raise the level of effort and performance in those around you, you 
are officially a leader" - Urban Meyer
"The greatest danger for most of us is not that our aim is too high and we miss 
it, but that it is too low and we reach it." -- Michelangelo Buonarroti
"Mediocore managers play checkers (assuming everyone is the same). Great 
managers play chess (acknowledging that everyone is unique)" - Marcus Buckingham
"If you're not failing every now and again, it's a sign you're not doing 
anything very innovative" - Woody Allen

Click here to join me in my Collaboration Meeting 
Room

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

Re: [ovs-discuss] [OVN] ovn-controller Incremental Processing scale testing

[Numan Siddique]

On Mon, Jun 24, 2019 at 1:51 PM aginwala  wrote:

> Hi:
> As per irc meeting discussion, some nice findings were already discussed
> by Numan (Thanks for sharing the details).  When changing external_ids for
> a claimed port e.g. ovn-nbctl set logical_switch_port sw0-port1
> external_ids:foo=bar triggers re-computation on local compute. I do see the
> same behavior. Numan is proposing a patch to skip computation for
> external_ids column for an already claimed port for port_binding table
> because of runtime_data, can't handle change for input SB_port_binding,
> fall back to recompute (
> https://github.com/openvswitch/ovs/blob/master/ovn/lib/inc-proc-eng.h#L77).
> However,  I don't see external_ids in port_binding table for the port being
> set explicitly when setting Interface table in the test code that Daniel
> posted [1] which could trigger extra re-computation in current test
> scenario.
>

ovn-northd just copies the external_ids of a logical switch port to
external_ids of port binding.  And networking-ovn makes use of external_ids
a lot.


>
> Also ovs-vsctl add-br test will also trigger re-computation on local
> compute and yes I can see the same. Since we don't have any handlers for
> Ports and Interfaces table similar to port_binding and other handlers @
> https://github.com/openvswitch/ovs/blob/master/ovn/controller/ovn-controller.c#L1769,
> adding a new bridge also causes re-computation on the local compute. Not
> sure if its required immediately because as per the patch shared by Daniel
> [1], I don't see any new test bridges getting created  apart from br-int
> and hence wont be much impact. Or may be I missed to see if they are also
> creating test bridges during testing. Of course, any new ovs-vsctl command
> for attaching/detaching vif will sure trigger recompute on br-int as and
> when VIF(vm) gets added/deleted to program the flow on local compute.
>

It would impact how the CMS creates the ovs port.

If suppose If I do something like below
---
ovs-vsctl add-port br-int foo
ovs-vsctl set interface foo type=internal
ovs-vsctl set Interface foo external_ids:iface-id=foo-id

and if ovn-controller gets 3 updates from ovsdb-server, this would result
in 3 recomputations.

However if I do
ovs-vsctl add-port br-int foo -- set interface foo type=internal -- set
interface foo external_ids:iface-id=foo-id

this could result in only 1 recomputation.

I think ovn-controller should handle the local ovsdb changes for
   1. external_ids of openvswitch table
   2. if an ovs interface's external_ids:iface-id  is updated.

We should try to ignore or any other changes to the local ovsdb.


> I didn't get a chance to verify when a chassisredirect port is claimed on
> a gateway chassis, it triggers computation on all computes registered with
> SB as per code
> https://github.com/openvswitch/ovs/blob/master/ovn/controller/binding.c#L722
> which was also raises further optimization for chassisredirect flow that
> Numan is suggesting.
>
> 1.
> https://github.com/danalsan/browbeat/commit/0ff72da52ddf17aa9f7269f191eebd890899bdad
>
>
I submitted the patches just now to address some of the issues -
https://patchwork.ozlabs.org/project/openvswitch/list/?series=115737

I also ran the test with these patches, but it didn't help in any
improvement. Although the patches I submitted avoids  recomputation
for some of the scenarios, I think I still need to dig further to see
what's causing the performance impact when compared with non IP patches,

Thanks
Numan

On Fri, Jun 21, 2019 at 12:32 AM Han Zhou  wrote:
>
>>
>>
>> On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique 
>> wrote:
>> >
>> >
>> >
>> > On Fri, Jun 21, 2019, 11:47 AM Han Zhou  wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jun 11, 2019 at 9:16 AM Daniel Alvarez Sanchez <
>> dalva...@redhat.com> wrote:
>> >> >
>> >> > Thanks a lot Han for the answer!
>> >> >
>> >> > On Tue, Jun 11, 2019 at 5:57 PM Han Zhou  wrote:
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Tue, Jun 11, 2019 at 5:12 AM Dumitru Ceara 
>> wrote:
>> >> > > >
>> >> > > > On Tue, Jun 11, 2019 at 10:40 AM Daniel Alvarez Sanchez
>> >> > > >  wrote:
>> >> > > > >
>> >> > > > > Hi Han, all,
>> >> > > > >
>> >> > > > > Lucas, Numan and I have been doing some 'scale' testing of
>> OpenStack
>> >> > > > > using OVN and wanted to present some results and issues that
>> we've
>> >> > > > > found with the Incremental Processing feature in
>> ovn-controller. Below
>> >> > > > > is the scenario that we executed:
>> >> > > > >
>> >> > > > > * 7 baremetal nodes setup: 3 controllers (running
>> >> > > > > ovn-northd/ovsdb-servers in A/P with pacemaker) + 4 compute
>> nodes. OVS
>> >> > > > > 2.10.
>> >> > > > > * The test consists on:
>> >> > > > >   - Create openstack network (OVN LS), subnet and router
>> >> > > > >   - Attach subnet to the router and set gw to the external
>> network
>> >> > > > >   - Create an OpenStack port and apply a Security Group (ACLs
>> to allow
>> >> > > > > UDP, SSH and ICMP).
>> 

Re: [ovs-discuss] [OVN] ovn-controller Incremental Processing scale testing

[aginwala]

Hi:
As per irc meeting discussion, some nice findings were already discussed by
Numan (Thanks for sharing the details).  When changing external_ids for a
claimed port e.g. ovn-nbctl set logical_switch_port sw0-port1
external_ids:foo=bar triggers re-computation on local compute. I do see the
same behavior. Numan is proposing a patch to skip computation for
external_ids column for an already claimed port for port_binding table
because of runtime_data, can't handle change for input SB_port_binding,
fall back to recompute (
https://github.com/openvswitch/ovs/blob/master/ovn/lib/inc-proc-eng.h#L77).
However,  I don't see external_ids in port_binding table for the port being
set explicitly when setting Interface table in the test code that Daniel
posted [1] which could trigger extra re-computation in current test
scenario.

Also ovs-vsctl add-br test will also trigger re-computation on local
compute and yes I can see the same. Since we don't have any handlers for
Ports and Interfaces table similar to port_binding and other handlers @
https://github.com/openvswitch/ovs/blob/master/ovn/controller/ovn-controller.c#L1769,
adding a new bridge also causes re-computation on the local compute. Not
sure if its required immediately because as per the patch shared by Daniel
[1], I don't see any new test bridges getting created  apart from br-int
and hence wont be much impact. Or may be I missed to see if they are also
creating test bridges during testing. Of course, any new ovs-vsctl command
for attaching/detaching vif will sure trigger recompute on br-int as and
when VIF(vm) gets added/deleted to program the flow on local compute.

I didn't get a chance to verify when a chassisredirect port is claimed on a
gateway chassis, it triggers computation on all computes registered with SB
as per code
https://github.com/openvswitch/ovs/blob/master/ovn/controller/binding.c#L722
which was also raises further optimization for chassisredirect flow that
Numan is suggesting.

1.
https://github.com/danalsan/browbeat/commit/0ff72da52ddf17aa9f7269f191eebd890899bdad

On Fri, Jun 21, 2019 at 12:32 AM Han Zhou  wrote:

>
>
> On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique 
> wrote:
> >
> >
> >
> > On Fri, Jun 21, 2019, 11:47 AM Han Zhou  wrote:
> >>
> >>
> >>
> >> On Tue, Jun 11, 2019 at 9:16 AM Daniel Alvarez Sanchez <
> dalva...@redhat.com> wrote:
> >> >
> >> > Thanks a lot Han for the answer!
> >> >
> >> > On Tue, Jun 11, 2019 at 5:57 PM Han Zhou  wrote:
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Tue, Jun 11, 2019 at 5:12 AM Dumitru Ceara 
> wrote:
> >> > > >
> >> > > > On Tue, Jun 11, 2019 at 10:40 AM Daniel Alvarez Sanchez
> >> > > >  wrote:
> >> > > > >
> >> > > > > Hi Han, all,
> >> > > > >
> >> > > > > Lucas, Numan and I have been doing some 'scale' testing of
> OpenStack
> >> > > > > using OVN and wanted to present some results and issues that
> we've
> >> > > > > found with the Incremental Processing feature in
> ovn-controller. Below
> >> > > > > is the scenario that we executed:
> >> > > > >
> >> > > > > * 7 baremetal nodes setup: 3 controllers (running
> >> > > > > ovn-northd/ovsdb-servers in A/P with pacemaker) + 4 compute
> nodes. OVS
> >> > > > > 2.10.
> >> > > > > * The test consists on:
> >> > > > >   - Create openstack network (OVN LS), subnet and router
> >> > > > >   - Attach subnet to the router and set gw to the external
> network
> >> > > > >   - Create an OpenStack port and apply a Security Group (ACLs
> to allow
> >> > > > > UDP, SSH and ICMP).
> >> > > > >   - Bind the port to one of the 4 compute nodes (randomly) by
> >> > > > > attaching it to a network namespace.
> >> > > > >   - Wait for the port to be ACTIVE in Neutron ('up == True' in
> NB)
> >> > > > >   - Wait until the test can ping the port
> >> > > > > * Running browbeat/rally with 16 simultaneous process to
> execute the
> >> > > > > test above 150 times.
> >> > > > > * When all the 150 'fake VMs' are created, browbeat will delete
> all
> >> > > > > the OpenStack/OVN resources.
> >> > > > >
> >> > > > > We first tried with OVS/OVN 2.10 and pulled some results which
> showed
> >> > > > > 100% success but ovn-controller is quite loaded (as expected)
> in all
> >> > > > > the nodes especially during the deletion phase:
> >> > > > >
> >> > > > > - Compute node: https://imgur.com/a/tzxfrIR
> >> > > > > - Controller node (ovn-northd and ovsdb-servers):
> https://imgur.com/a/8ffKKYF
> >> > > > >
> >> > > > > After conducting the tests above, we replaced ovn-controller in
> all 7
> >> > > > > nodes by the one with the current master branch (actually from
> last
> >> > > > > week). We also replaced ovn-northd and ovsdb-servers but the
> >> > > > > ovs-vswitchd has been left untouched (still on 2.10). The
> expected
> >> > > > > results were to get less ovn-controller CPU usage and also
> better
> >> > > > > times due to the Incremental Processing feature introduced
> recently.
> >> > > > > However, the results don't look very good:
> >> > > > >
> >> > > > >