Re: [ovs-discuss] OFPACT_DEC_TTL in kernel space

[Justin Pettit]

> On Jun 25, 2019, at 2:02 PM, Sagar A  wrote:
> 
>> Is there a particular use-case that requires decrement?
>> 
> I have rule which wants to match on 'dst_ip' only. Since, code is touching 
> 'ttl', it becomes a match condition. For flows with same 'dst_ip' and 
> different ttls, result in different flows instead of having only one flow 
> with 'dst_ip' as match condition. Any suggestion to solve the problem?

You are directly calling the kernel datapath interface and not using 
ovs-vswitchd?  If you're using ovs-vswitchd, it will take care of matching the 
TTL for you when it pushes the flow down to the kernel.  If not, then you'd 
need to propose changes to the kernel.  I don't know whether they would accept 
such a patch without a compelling reason, since there's arguably a more 
flexible (although less efficient in some cases) mechanism already in place.

--Justin


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

Re: [ovs-discuss] OFPACT_DEC_TTL in kernel space

[Sagar A]

Hello Justin,

Thank you for reply.
On Mon, Jun 24, 2019 at 5:39 PM Justin Pettit  wrote:

> 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?
>

I have rule which wants to match on 'dst_ip' only. Since, code is touching
'ttl', it becomes a match condition. For flows with same 'dst_ip' and
different ttls, result in different flows instead of having only one flow
with 'dst_ip' as match condition. Any suggestion to solve the problem?


>
> --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

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

[Murali Veluru]

Thank Ian Stokes,

It is very helpful for us. I was trying to apply these patches on 
openvswitch-2.11.1 repository, it was failing.

Some of the files are not found.



Could you, please let me know suitable version of ovs, where these patches will 
get apply successfully.

Along with which  version of DPDK need to use for compilation?



Regards

Murali




From: Ian Stokes 
Sent: Monday, June 24, 2019 10:56:34 PM
To: Murali Veluru; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] TSO changes with OVS-DPDK for higher throughput

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

Re: [ovs-discuss] OVS + VXLAN Performance

[Guru Shetty]

How do you define "poor" performance? If it is awfully low, it is likely
that your [ outer MTU < (inner MTU + vxlan header)]. You can reduce your
inner MTU and see the difference.

On Mon, 24 Jun 2019 at 06:34, Heim, Dennis  wrote:

> 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
>
> [image: cid:image001.png@01D10DD2.7FC81F90]
> 
>
> [image: cid:image002.png@01D10DD2.7FC81F90][image:
> cid:image003.png@01D10DD2.7FC81F90] <+13142121814>[image:
> 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
>
___
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/25/2019 12:30 PM, Murali Veluru wrote:

Thank Ian Stokes,

It is very helpful for us. I was trying to apply these patches on 
openvswitch-2.11.1 repository, it was failing.


Some of the files are not found.

Could you, please let me know suitable version of ovs, where these 
patches will get apply successfully.


Hi Murali,

the commit these patches can be applied to are listed in the cover 
letter for the patchsets.


I believe you want to check out the following commit from the ovs master 
branch (this commit was pre 2.11 release)


adb3f0b ("python: Avoid flake8 warning for unused variables.")

You should then be able to apply the mutliseg patchset on top of this 
commit (Multiseg is a pre-requirement for enabling TSO, see link below)


https://patchwork.ozlabs.org/project/openvswitch/list/?series=85802&state=*

Once these are applied you should be able to apply the TSO enablement 
patchset then (see link below).


https://patchwork.ozlabs.org/project/openvswitch/list/?series=85807&state=*

When using the commit as outlined above do these apply for you?

Regards
Ian


Along with which  version of DPDK need to use for compilation?

Regards

Murali


*From:* Ian Stokes 
*Sent:* Monday, June 24, 2019 10:56:34 PM
*To:* Murali Veluru; ovs-discuss@openvswitch.org
*Subject:* Re: [ovs-discuss] TSO changes with OVS-DPDK for higher 
throughput

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] [OVN] Aging mechanism for MAC_Binding table

[Daniel Alvarez Sanchez]

Hi folks,

Lately we've been trying to solve certain issues related to stale
entries in the MAC_Binding table (e.g. [0]). On the other hand, for
the OpenStack + Octavia (Load Balancing service) use case, we see that
a reused VIP can be as well affected by stale entries in this table
due to the fact that it's never bound to a VIF so ovn-controller won't
claim it and send the GARPs to update the neighbors.

I'm not sure if other scenarios may suffer from this issue but seems
reasonable to have an aging mechanism (as we discussed at some point
in the past) that makes unused/old entries to expire. After talking to
Numan on IRC, since a new pinctrl thread has been introduced recently
[1], it'd be nice to implement this aging mechanism there.
At the same time we'd be also reducing the amount of entries for long
lived systems as it'd grow indefinitely.

Any thoughts?

Thanks!
Daniel

PS. With regards to the 'unused' vs 'old' entries I think it has to be
'old' rather than 'unused' as I don't see a way to reset the TTL of a
MAC_Binding entry when we see packets coming. The implication is that
we'll be seeing ARPs sent out more often when perhaps they're not
needed. This also leads to the discussion of making the cache timeout
configurable.

[0] 
https://github.com/openvswitch/ovs/commit/81e928526b8a9393b90785fb0a9c82d79570ef84
[1] 
https://github.com/openvswitch/ovs/commit/3594ffab6b4b423aa635a313f6b304180d7dbaf7
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss