Re: [ovs-discuss] bond-rebalance-interval

[Justin Pettit]

Can you provide the command and options that you used? I assume it was 
ovs-vsctl. 

--Justin


> On Mar 8, 2018, at 8:11 PM, Chris Boley  wrote:
> 
> Justin I set the value at 5000
> I tried it via my interfaces file stanza and also by way of the 
> extra-options: in a live command. 
> It produced no errors in either method but when I look at the bridge, there 
> it is.. 1 every time.
> 
>> On Thu, Mar 8, 2018 at 9:06 PM Justin Pettit  wrote:
>> It should work.  How are you setting it?
>> 
>> --Justin
>> 
>> 
>> > On Mar 8, 2018, at 5:57 PM, Chris Boley  wrote:
>> >
>> > bond-rebalance-interval=1
>> >
>> > If I set this option to any other setting such as 5000 for example it 
>> > always shows 1 on the output of an sudo ovs-vsctl list port vbond0 
>> > command.
>> >
>> > My version is 2.5.2. Is this rebalance interval negotiated between the 
>> > Cisco etherchannel that I am peering with happens to depend on what the 
>> > peer is willing to do or am I missing something?
>> >
>> > Thank you,
>> > CB
>> >
>> > ___
>> > 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] bond-rebalance-interval

[Chris Boley]

Ben if you could suggest how I can assist you in reproduction of the
unusual behavior I’d be happy to share anything I can with you or help out
in any way that I can.

On Thu, Mar 8, 2018 at 9:17 PM Ben Pfaff  wrote:

> On Thu, Mar 08, 2018 at 08:57:45PM -0500, Chris Boley wrote:
> > bond-rebalance-interval=1
> >
> > If I set this option to any other setting such as 5000 for example it
> > always shows 1 on the output of an sudo ovs-vsctl list port vbond0
> > command.
>
> That is an unusual behavior, which surprises me.  I have been unable to
> reproduce it.  Can you help me reproduce it?
>
> > My version is 2.5.2. Is this rebalance interval negotiated between the
> > Cisco etherchannel that I am peering with happens to depend on what the
> > peer is willing to do or am I missing something?
>
> No, it's not negotiated, it's a local setting.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] bond-rebalance-interval

[Chris Boley]

Justin I set the value at 5000
I tried it via my interfaces file stanza and also by way of the
extra-options: in a live command.
It produced no errors in either method but when I look at the bridge, there
it is.. 1 every time.

On Thu, Mar 8, 2018 at 9:06 PM Justin Pettit  wrote:

> It should work.  How are you setting it?
>
> --Justin
>
>
> > On Mar 8, 2018, at 5:57 PM, Chris Boley  wrote:
> >
> > bond-rebalance-interval=1
> >
> > If I set this option to any other setting such as 5000 for example it
> always shows 1 on the output of an sudo ovs-vsctl list port vbond0
> command.
> >
> > My version is 2.5.2. Is this rebalance interval negotiated between the
> Cisco etherchannel that I am peering with happens to depend on what the
> peer is willing to do or am I missing something?
> >
> > Thank you,
> > CB
> >
> > ___
> > 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] bond-rebalance-interval

[Ben Pfaff]

On Thu, Mar 08, 2018 at 08:57:45PM -0500, Chris Boley wrote:
> bond-rebalance-interval=1
> 
> If I set this option to any other setting such as 5000 for example it
> always shows 1 on the output of an sudo ovs-vsctl list port vbond0
> command.

That is an unusual behavior, which surprises me.  I have been unable to
reproduce it.  Can you help me reproduce it?

> My version is 2.5.2. Is this rebalance interval negotiated between the
> Cisco etherchannel that I am peering with happens to depend on what the
> peer is willing to do or am I missing something?

No, it's not negotiated, it's a local setting.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] bond-rebalance-interval

[Justin Pettit]

It should work.  How are you setting it?

--Justin


> On Mar 8, 2018, at 5:57 PM, Chris Boley  wrote:
> 
> bond-rebalance-interval=1
> 
> If I set this option to any other setting such as 5000 for example it always 
> shows 1 on the output of an sudo ovs-vsctl list port vbond0 command.
> 
> My version is 2.5.2. Is this rebalance interval negotiated between the Cisco 
> etherchannel that I am peering with happens to depend on what the peer is 
> willing to do or am I missing something?
> 
> Thank you,
> CB
> 
> ___
> 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] bond-rebalance-interval

[Chris Boley]

bond-rebalance-interval=1

If I set this option to any other setting such as 5000 for example it
always shows 1 on the output of an sudo ovs-vsctl list port vbond0
command.

My version is 2.5.2. Is this rebalance interval negotiated between the
Cisco etherchannel that I am peering with happens to depend on what the
peer is willing to do or am I missing something?

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

Re: [ovs-discuss] [ovs-dev] Passive openflow proxy

[Xiao Liang]

Hi Ben and Bill,

Thanks for your reply.

Controller-to-switch messages can be handled by maintaining a cache of
outstanding xid mappings.
Controller state and async messages handling is a problem. I think the
proxy can maintain an internal state for each controller, remain
ROLE_EQUAL to switches, and SET_ASYNC to the OR-ed value of all
controllers.
I'm going to post a patch of prototype that handles
controller-to-switch messages.

Thanks,
Xiao

On Fri, Mar 9, 2018 at 3:38 AM, William Fisher
 wrote:
> Hi Xiao,
>
> You are proposing an OpenFlow proxy that passively accepts connections from
> OF switches, and feeds them upwards to multiple active/passive controller
> clients C1 and C2.  You want to use ovs-ofctl as one of these clients.
> ovs-ofctl would make an active connection to the proxy to get access to one
> of several existing OF control connections. Please let me know if my summary
> is incorrect.

Yes, that's correct.

>
> A couple of issues:
>
> 1. How does ovs-ofctl tell the proxy which datapath_id it is interested in?

The proxy can open a socket on behalf of each switch, identified by
switch connection endpoint or datapath_id.

> 2. xid's need to be virtualized.
>
> If client C1 issues a FLOW_STATS request with xid 1, the reply should go to
> C1 only.  This may require that the proxy re-maps xid's to a different
> number when sent to the real OF connection.
>
> 3. If a client issues a read-write OF command (e.g. SET_ASYNC), it is
> understood that this changes the datapath state for all clients.
>
> Are there any other issues or situations that such a tool would need to
> handle?
>
> Regards,
> -Bill
>
>
>
>
> On Thu, Mar 8, 2018 at 10:30 AM Ben Pfaff  wrote:
>>
>> On Thu, Mar 08, 2018 at 07:51:23PM +0800, Xiao Liang wrote:
>> > In my experience, one thing I feel inconvenient is that some switches
>> > don't support controller-initiated connections. It would be helpful
>> > for testing and debugging if ovs-ofctl could be used.
>> > I'd propose an openflow proxy which is responsible for accepting and
>> > maintaining connections from switches, opening sockets for controllers
>> > to connect, and proxy messages between them. So that openflow tools
>> > like ovs-ofctl can operate on these switches.
>> > Another approach might be adding a "passive mode" to ovs-ofctl, which
>> > listens for connections, and opens an interactive shell to run
>> > commands.
>>
>> I guess that this is a problem with non-OVS switches?  OVS does support
>> controller-initiated connections.
>>

Yes, mainly for non-OVS switches.

>> The proxy that you describe is going to be difficult to write because to
>> be most useful it would have to multiplex multiple connections into a
>> single connection.  OpenFlow connections are not stateless, so it would
>> have to figure out how to effectively partition the desires of multiple
>> clients into a single session.  I haven't thought through all the
>> necessary logic, but it would not be trivial.
>>
>> I think that the ovs-ofctl passive mode that you describe is similar in
>> practice to writing a proxy: probably, it would internally start a proxy
>> and then allow the user to access it.  It might be easiest to actually
>> implement it as a mode for the proxy that starts a subshell.
>>
>> I think that this is a worthy project, for someone for whom support for
>> non-OVS switches is important, and I'd encourage a motivated developer
>> to work on it.
>> ___
>> 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] OVN Database sizes - Auto compact feature

[Daniel Alvarez Sanchez]

Ok, I've just sent a patch and if you're not convinced we can
just do the 2x change. Thanks a lot!
Daniel

On Thu, Mar 8, 2018 at 10:19 PM, Ben Pfaff  wrote:

> I guess I wouldn't object.
>
> On Thu, Mar 08, 2018 at 10:11:11PM +0100, Daniel Alvarez Sanchez wrote:
> > Thanks Ben and Mark. I'd be okay with 2x.
> > Don't you think that apart from that it can still be good to compact
> after
> > a
> > certain amount of time (like 1 day) if the number of transactions is > 0
> > regardless of the size?
> >
> > On Thu, Mar 8, 2018 at 10:00 PM, Ben Pfaff  wrote:
> >
> > > It would be trivial to change 4x to 2x.  4x was just the suggestion in
> > > the Raft thesis.  If 2x would make everyone a little more comfortable,
> > > let's make that change.
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Mark Michelson]

On 03/08/2018 02:54 PM, Daniel Alvarez Sanchez wrote:
I agree with you Mark. I tried to check how much it would shrink with 
1800 ports in the system:


[stack@ovn ovs]$ sudo ovn-nbctl list Logical_Switch_Port | grep uuid | wc -l
1809
[stack@ovn ovs]$ sudo ovn-sbctl list Logical_Flow | grep uuid | wc -l
50780
[stack@ovn ovs]$ ls -alh ovn*.db
-rw-r--r--. 1 stack stack 15M Mar  8 15:56 ovnnb_db.db
-rw-r--r--. 1 stack stack 61M Mar  8 15:56 ovnsb_db.db
[stack@ovn ovs]$ sudo ovs-appctl -t 
/usr/local/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/compact
[stack@ovn ovs]$ sudo ovs-appctl -t 
/usr/local/var/run/openvswitch/ovnnb_db.ctl ovsdb-server/compact

[stack@ovn ovs]$ ls -alh ovn*.db
-rw-r--r--. 1 stack stack 5.8M Mar  8 20:45 ovnnb_db.db
-rw-r--r--. 1 stack stack  23M Mar  8 20:45 ovnsb_db.db

As you can see, with ~50K lflows, the database min size would be ~23M 
while the NB database
is much smaller. Still I think we need to do something to not allow 
delay the compact task to
kick in this much unnecessarily. Or maybe we want some sort of 
configuration (ie. normal, aggressive,...)
for this since in some situations it may help to have the full log of 
the DB (although this can be
achieved through periodic backups :?). That said, I'm not a big fan of 
such configs but...




I'm also not a big fan of that sort of configuration. Based on Ben's 
replies here, I like the idea of being more aggressive with the 
compacting. The two ideas proposed here, compact at double the size 
instead of 4x and ensure a compact happens once every 24 hours, sound 
like good mitigations to me.





On Thu, Mar 8, 2018 at 9:31 PM, Mark Michelson > wrote:


Most of the data in this thread has been pretty easily explainable
based on what I've seen in the code compared with the nature of the
data in the southbound database.

The southbound database tends to have more data in it than other
databases in OVS, due especially to the Logical_Flow table. The
result is that auto shrinking of the database does not shrink it
down by as much as other databases. You can see in Daniel's graphs
that each time the southbound database is shrunk, its "base" size
ends up noticeably larger than it previously was.

Couple that with the fact that the database has to increase to 4x
its previous snapshot size in order to be shrunk, and you can end up
with a situation after a while where the "shrunk" southbound
database is 750MB, and it won't shrink again until it exceeds 3GB.

To fix this, I think there are a few things that can be done:

* Somehow make the southbound database have less data in it. I don't
have any real good ideas for how to do this, and doing this in a
backwards-compatible way will be difficult.

* Ease the requirements for shrinking a database. For instance, once
the database reaches a certain size, maybe it doesn't need to grow
by 4x in order to be a candidate for shrinking. Maybe it only needs
to double in size. Or, there could be some time cutoff where the
database always will be shrunk. So for instance, every hour, always
shrink the database, no matter how much activity has occurred in it
(okay, maybe not if there have been 0 transactions).


Maybe we can just do the the shrink if the last compact took place >24h 
ago regardless of the other conditions.
I can send a patch for this if you guys like the idea. It's some sort of 
"cleanup task" just in case and seems harmless.

What do you say?



On 03/07/2018 02:50 PM, Ben Pfaff wrote:

OK.

I guess we need to investigate this issue from the basics.

On Wed, Mar 07, 2018 at 09:02:02PM +0100, Daniel Alvarez Sanchez
wrote:

With OVS 2.8 branch it never shrank when I started to delete
the ports since
the DB sizes didn't grow, which makes sense to me. The
conditions weren't
met for further compaction.
See attached image.

NB:

2018-03-07T18:25:49.269Z|9|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (647.317 seconds old, 436
transactions, 10505382
bytes)

2018-03-07T18:35:51.414Z|00012|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (602.089 seconds old, 431
transactions, 29551917
bytes)

2018-03-07T18:45:52.263Z|00015|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (600.563 seconds old, 463
transactions, 52843231
bytes)

2018-03-07T18:55:53.810Z|00016|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (601.128 seconds old, 365
transactions, 57618931
bytes)


SB:

2018-03-07T18:33:24.927Z|9|ovsdb_file|INFO|/opt/stack/d

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

I guess I wouldn't object.

On Thu, Mar 08, 2018 at 10:11:11PM +0100, Daniel Alvarez Sanchez wrote:
> Thanks Ben and Mark. I'd be okay with 2x.
> Don't you think that apart from that it can still be good to compact after
> a
> certain amount of time (like 1 day) if the number of transactions is > 0
> regardless of the size?
> 
> On Thu, Mar 8, 2018 at 10:00 PM, Ben Pfaff  wrote:
> 
> > It would be trivial to change 4x to 2x.  4x was just the suggestion in
> > the Raft thesis.  If 2x would make everyone a little more comfortable,
> > let's make that change.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Daniel Alvarez Sanchez]

Thanks Ben and Mark. I'd be okay with 2x.
Don't you think that apart from that it can still be good to compact after
a
certain amount of time (like 1 day) if the number of transactions is > 0
regardless of the size?

On Thu, Mar 8, 2018 at 10:00 PM, Ben Pfaff  wrote:

> It would be trivial to change 4x to 2x.  4x was just the suggestion in
> the Raft thesis.  If 2x would make everyone a little more comfortable,
> let's make that change.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

It would be trivial to change 4x to 2x.  4x was just the suggestion in
the Raft thesis.  If 2x would make everyone a little more comfortable,
let's make that change.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Daniel Alvarez Sanchez]

I agree with you Mark. I tried to check how much it would shrink with 1800
ports in the system:

[stack@ovn ovs]$ sudo ovn-nbctl list Logical_Switch_Port | grep uuid | wc -l
1809
[stack@ovn ovs]$ sudo ovn-sbctl list Logical_Flow | grep uuid | wc -l


50780
[stack@ovn ovs]$ ls -alh ovn*.db


-rw-r--r--. 1 stack stack 15M Mar  8 15:56 ovnnb_db.db
-rw-r--r--. 1 stack stack 61M Mar  8 15:56 ovnsb_db.db
[stack@ovn ovs]$ sudo ovs-appctl -t
/usr/local/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/compact
[stack@ovn ovs]$ sudo ovs-appctl -t
/usr/local/var/run/openvswitch/ovnnb_db.ctl ovsdb-server/compact


[stack@ovn ovs]$ ls -alh ovn*.db
-rw-r--r--. 1 stack stack 5.8M Mar  8 20:45 ovnnb_db.db
-rw-r--r--. 1 stack stack  23M Mar  8 20:45 ovnsb_db.db

As you can see, with ~50K lflows, the database min size would be ~23M while
the NB database
is much smaller. Still I think we need to do something to not allow delay
the compact task to
kick in this much unnecessarily. Or maybe we want some sort of
configuration (ie. normal, aggressive,...)
for this since in some situations it may help to have the full log of the
DB (although this can be
achieved through periodic backups :?). That said, I'm not a big fan of such
configs but...



On Thu, Mar 8, 2018 at 9:31 PM, Mark Michelson  wrote:

> Most of the data in this thread has been pretty easily explainable based
> on what I've seen in the code compared with the nature of the data in the
> southbound database.
>
> The southbound database tends to have more data in it than other databases
> in OVS, due especially to the Logical_Flow table. The result is that auto
> shrinking of the database does not shrink it down by as much as other
> databases. You can see in Daniel's graphs that each time the southbound
> database is shrunk, its "base" size ends up noticeably larger than it
> previously was.
>
> Couple that with the fact that the database has to increase to 4x its
> previous snapshot size in order to be shrunk, and you can end up with a
> situation after a while where the "shrunk" southbound database is 750MB,
> and it won't shrink again until it exceeds 3GB.
>
> To fix this, I think there are a few things that can be done:
>
> * Somehow make the southbound database have less data in it. I don't have
> any real good ideas for how to do this, and doing this in a
> backwards-compatible way will be difficult.
>
> * Ease the requirements for shrinking a database. For instance, once the
> database reaches a certain size, maybe it doesn't need to grow by 4x in
> order to be a candidate for shrinking. Maybe it only needs to double in
> size. Or, there could be some time cutoff where the database always will be
> shrunk. So for instance, every hour, always shrink the database, no matter
> how much activity has occurred in it (okay, maybe not if there have been 0
> transactions).


Maybe we can just do the the shrink if the last compact took place >24h ago
regardless of the other conditions.
I can send a patch for this if you guys like the idea. It's some sort of
"cleanup task" just in case and seems harmless.
What do you say?

>
>
> On 03/07/2018 02:50 PM, Ben Pfaff wrote:
>
>> OK.
>>
>> I guess we need to investigate this issue from the basics.
>>
>> On Wed, Mar 07, 2018 at 09:02:02PM +0100, Daniel Alvarez Sanchez wrote:
>>
>>> With OVS 2.8 branch it never shrank when I started to delete the ports
>>> since
>>> the DB sizes didn't grow, which makes sense to me. The conditions weren't
>>> met for further compaction.
>>> See attached image.
>>>
>>> NB:
>>> 2018-03-07T18:25:49.269Z|9|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnnb_db.db:
>>> compacting database online (647.317 seconds old, 436 transactions,
>>> 10505382
>>> bytes)
>>> 2018-03-07T18:35:51.414Z|00012|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnnb_db.db:
>>> compacting database online (602.089 seconds old, 431 transactions,
>>> 29551917
>>> bytes)
>>> 2018-03-07T18:45:52.263Z|00015|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnnb_db.db:
>>> compacting database online (600.563 seconds old, 463 transactions,
>>> 52843231
>>> bytes)
>>> 2018-03-07T18:55:53.810Z|00016|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnnb_db.db:
>>> compacting database online (601.128 seconds old, 365 transactions,
>>> 57618931
>>> bytes)
>>>
>>>
>>> SB:
>>> 2018-03-07T18:33:24.927Z|9|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnsb_db.db:
>>> compacting database online (1102.840 seconds old, 775 transactions,
>>> 10505486 bytes)
>>> 2018-03-07T18:43:27.569Z|00012|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnsb_db.db:
>>> compacting database online (602.394 seconds old, 445 transactions,
>>> 15293972
>>> bytes)
>>> 2018-03-07T18:53:31.664Z|00015|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnsb_db.db:
>>> compacting database online (603.605 seconds old, 385 transactions,
>>> 19282371
>>> bytes)
>>> 2018-03-07T19:03:42.116Z|00031|ovsdb_file|INFO|/opt/stack/
>>> data/ovs/ovnsb_db.db:
>>> compacting database online (607.542 seconds old, 371 transacti

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Mark Michelson]

Most of the data in this thread has been pretty easily explainable based 
on what I've seen in the code compared with the nature of the data in 
the southbound database.


The southbound database tends to have more data in it than other 
databases in OVS, due especially to the Logical_Flow table. The result 
is that auto shrinking of the database does not shrink it down by as 
much as other databases. You can see in Daniel's graphs that each time 
the southbound database is shrunk, its "base" size ends up noticeably 
larger than it previously was.


Couple that with the fact that the database has to increase to 4x its 
previous snapshot size in order to be shrunk, and you can end up with a 
situation after a while where the "shrunk" southbound database is 750MB, 
and it won't shrink again until it exceeds 3GB.


To fix this, I think there are a few things that can be done:

* Somehow make the southbound database have less data in it. I don't 
have any real good ideas for how to do this, and doing this in a 
backwards-compatible way will be difficult.


* Ease the requirements for shrinking a database. For instance, once the 
database reaches a certain size, maybe it doesn't need to grow by 4x in 
order to be a candidate for shrinking. Maybe it only needs to double in 
size. Or, there could be some time cutoff where the database always will 
be shrunk. So for instance, every hour, always shrink the database, no 
matter how much activity has occurred in it (okay, maybe not if there 
have been 0 transactions).


On 03/07/2018 02:50 PM, Ben Pfaff wrote:

OK.

I guess we need to investigate this issue from the basics.

On Wed, Mar 07, 2018 at 09:02:02PM +0100, Daniel Alvarez Sanchez wrote:

With OVS 2.8 branch it never shrank when I started to delete the ports since
the DB sizes didn't grow, which makes sense to me. The conditions weren't
met for further compaction.
See attached image.

NB:
2018-03-07T18:25:49.269Z|9|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (647.317 seconds old, 436 transactions, 10505382
bytes)
2018-03-07T18:35:51.414Z|00012|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (602.089 seconds old, 431 transactions, 29551917
bytes)
2018-03-07T18:45:52.263Z|00015|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (600.563 seconds old, 463 transactions, 52843231
bytes)
2018-03-07T18:55:53.810Z|00016|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
compacting database online (601.128 seconds old, 365 transactions, 57618931
bytes)


SB:
2018-03-07T18:33:24.927Z|9|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
compacting database online (1102.840 seconds old, 775 transactions,
10505486 bytes)
2018-03-07T18:43:27.569Z|00012|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
compacting database online (602.394 seconds old, 445 transactions, 15293972
bytes)
2018-03-07T18:53:31.664Z|00015|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
compacting database online (603.605 seconds old, 385 transactions, 19282371
bytes)
2018-03-07T19:03:42.116Z|00031|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
compacting database online (607.542 seconds old, 371 transactions, 23538784
bytes)




On Wed, Mar 7, 2018 at 7:18 PM, Daniel Alvarez Sanchez 
wrote:


No worries, I just triggered the test now running OVS compiled out of
2.8 branch (2.8.3). I'll post the results and investigate too.

I have just sent a patch to fix the timing issue we can see in the traces I
posted. I applied it and it works, I believe it's good to fix as it gives
us
an idea of how frequent the compact is, and also to backport if you
agree with it.

Thanks!

On Wed, Mar 7, 2018 at 7:13 PM, Ben Pfaff  wrote:


OK, thanks.

If this is a lot of trouble, let me know and I'll investigate directly
instead of on the basis of a suspected regression.

On Wed, Mar 07, 2018 at 07:06:50PM +0100, Daniel Alvarez Sanchez wrote:

All right, I'll repeat it with code in branch-2.8.
Will post the results once the test finishes.
Daniel

On Wed, Mar 7, 2018 at 7:03 PM, Ben Pfaff  wrote:


On Wed, Mar 07, 2018 at 05:53:15PM +0100, Daniel Alvarez Sanchez

wrote:

Repeated the test with 1000 ports this time. See attached image.
For some reason, the sizes grow while deleting the ports (the
deletion task starts at around x=2500). The weird thing is why
they keep growing and the online compact doesn't work as when
I do it through ovs-appctl tool.

I suspect this is a bug and eventually it will grow and grow unless
we manually compact the db.


Would you mind trying out an older ovsdb-server, for example the one
from OVS 2.8?  Some of the logic in ovsdb-server around compaction
changed in OVS 2.9, so it would be nice to know whether this was a
regression or an existing bug.











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

Re: [ovs-discuss] [ovs-dev] Passive openflow proxy

[William Fisher]

Hi Xiao,

You are proposing an OpenFlow proxy that passively accepts connections from
OF switches, and feeds them upwards to multiple active/passive controller
clients C1 and C2.  You want to use ovs-ofctl as one of these clients.
ovs-ofctl would make an active connection to the proxy to get access to one
of several existing OF control connections. Please let me know if my
summary is incorrect.

A couple of issues:

1. How does ovs-ofctl tell the proxy which datapath_id it is interested in?

I assume ovs-ofctl expects to connect to a single datapath. It may issue a
FEATURES_REQUEST message to find out who it is talking to.  This sounds
like virtual hosting, so something like TLS SNI could be used.  Otherwise,
this requires modifications to the OF protocol (an EXPERIMENTER message or
custom HELLO element)

2. xid's need to be virtualized.

If client C1 issues a FLOW_STATS request with xid 1, the reply should go to
C1 only.  This may require that the proxy re-maps xid's to a different
number when sent to the real OF connection.

3. If a client issues a read-write OF command (e.g. SET_ASYNC), it is
understood that this changes the datapath state for all clients.

Are there any other issues or situations that such a tool would need to
handle?

Regards,
-Bill




On Thu, Mar 8, 2018 at 10:30 AM Ben Pfaff  wrote:

> On Thu, Mar 08, 2018 at 07:51:23PM +0800, Xiao Liang wrote:
> > In my experience, one thing I feel inconvenient is that some switches
> > don't support controller-initiated connections. It would be helpful
> > for testing and debugging if ovs-ofctl could be used.
> > I'd propose an openflow proxy which is responsible for accepting and
> > maintaining connections from switches, opening sockets for controllers
> > to connect, and proxy messages between them. So that openflow tools
> > like ovs-ofctl can operate on these switches.
> > Another approach might be adding a "passive mode" to ovs-ofctl, which
> > listens for connections, and opens an interactive shell to run
> > commands.
>
> I guess that this is a problem with non-OVS switches?  OVS does support
> controller-initiated connections.
>
> The proxy that you describe is going to be difficult to write because to
> be most useful it would have to multiplex multiple connections into a
> single connection.  OpenFlow connections are not stateless, so it would
> have to figure out how to effectively partition the desires of multiple
> clients into a single session.  I haven't thought through all the
> necessary logic, but it would not be trivial.
>
> I think that the ovs-ofctl passive mode that you describe is similar in
> practice to writing a proxy: probably, it would internally start a proxy
> and then allow the user to access it.  It might be easiest to actually
> implement it as a mode for the proxy that starts a subshell.
>
> I think that this is a worthy project, for someone for whom support for
> non-OVS switches is important, and I'd encourage a motivated developer
> to work on it.
> ___
> 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] The discrepancy in the Monitor request composition.

[Anil Jangam]

Ok, that answers my question. Thank you.

On Thu, Mar 8, 2018, 11:13 AM Ben Pfaff  wrote:

> No.  A JSON object can have any number of members.
>
> On Thu, Mar 08, 2018 at 11:06:21AM -0800, Anil Jangam wrote:
> > Thanks Ben for clarification. So it means one Monitor request can request
> > for only one Table monitoring, correct?
> >
> > On Thu, Mar 8, 2018 at 10:36 AM, Ben Pfaff  wrote:
> >
> > >  is a JSON object.  A JSON object maps from keys to
> > > values, so we only need one.
> > >
> > > Your specification for  is wrong because it says that
> > > it is a JSON array.  It is not.
> > >
> > > On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> > > > Hello Ben,
> > > >
> > > > I have one more observation. I request you to please read it
> carefully.
> > > If
> > > > we go by the current monitor method definition, there can be only
> > > > 
> > > > in one monitor RPC method. If it is expected to have only one
> > > > 
> > > > i.e. one table and an array of , then the current
> > > > specification is good.
> > > >
> > > > o  "method": "monitor"
> > > >
> > > > o  "params": [, , ]
> > > >
> > > > o  "id": 
> > > >
> > > >
> > > > However, if it is possible to specify multiple table monitoring in
> one
> > > RPC
> > > > method, IMHO the above syntax would change as below.
> > > >
> > > >
> > > > o  "method": "monitor"
> > > >
> > > > o  "params": [, , *]
> > > >
> > > > o  "id": 
> > > >
> > > >
> > > > For completeness, I am also specifying the syntax for
> .
> > > >
> > > > monitor-requests : [, *]
> > > >
> > > >
> > > > Let me know if this would be correct or if you think otherwise.
> > > >
> > > > /anil.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff  wrote:
> > > >
> > > > > Ah, OK, you're saying that there's a missing [] around the
> > > > > .  This goes back to a change that we made to the
> > > > > ovsdb-server protocol a long time ago to allow multiple
> > > > >  objects instead of just a single one.
> ovsdb-server
> > > > > still supports this form.  You can see this documented in
> > > > > Documentation/ref/ovsdb-server.7.rst:
> > > > >
> > > > > For backward compatibility, ``ovsdb-server`` currently permits
> a
> > > single
> > > > >  to be used instead of an array; it is
> treated as
> > > a
> > > > > single-element array.  Future versions of ``ovsdb-server``
> might
> > > > > remove this
> > > > > compatibility feature.
> > > > >
> > > > > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> > > > >
> > > > > Anyway, that's easy enough, so I sent a patch:
> > > > > https://patchwork.ozlabs.org/patch/882710/
> > > > >
> > > > > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > > > > Hello Ben,
> > > > > >
> > > > > > The  object maps the name of the table to be
> > > monitored
> > > > > >
> > > > > > to an array of  objects. Each 
> is
> > > an
> > > > > >
> > > > > > object with the following members:
> > > > > >
> > > > > >"columns": [*]optional
> > > > > >
> > > > > >"select": optional
> > > > > >
> > > > > >
> > > > > >
> > > > > > As the  maps the table name to be monitored to
> an
> > > array
> > > > > > of , my interpretation of it is as "Table Name
> <-->
> > > > > Array
> > > > > > of "
> > > > > >
> > > > > > I am giving an example message is given below.
> > > > > >
> > > > > > {
> > > > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > > > >   "method": "monitor",
> > > > > >   "params": [
> > > > > > "hardware_vtep",
> > > > > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > > > {
> > > > > >   "Physical_Locator": [
> > > > > > {
> > > > > >   "columns": [
> > > > > > "dst_ip",
> > > > > > "encapsulation_type",
> > > > > > "_uuid"
> > > > > >   ],
> > > > > >   "select": {
> > > > > > "initial": true,
> > > > > > "insert": true,
> > > > > > "delete": true,
> > > > > > "modify": true
> > > > > >   }
> > > > > > },
> > > > > > {
> > > > > >   "columns": [
> > > > > > "_uuid",
> > > > > > "locators"
> > > > > >   ],
> > > > > >   "select": {
> > > > > > "initial": true,
> > > > > > "insert": true,
> > > > > > "delete": true,
> > > > > > "modify": true
> > > > > >   }
> > > > > > }
> > > > > >   ]
> > > > > > }
> > > > > >   ]
> > > > > > }
> > > > > >
> > > > > >
> > > > > > /anil.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff  wrote:
> > > > > >
> > > > > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > The RFC7047 states below about the Monitor request.
> > > > > > > >
> > > > > > > > The request object has the
> > > > > > > >
> > > > > > > >following members:

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

No.  A JSON object can have any number of members.

On Thu, Mar 08, 2018 at 11:06:21AM -0800, Anil Jangam wrote:
> Thanks Ben for clarification. So it means one Monitor request can request
> for only one Table monitoring, correct?
> 
> On Thu, Mar 8, 2018 at 10:36 AM, Ben Pfaff  wrote:
> 
> >  is a JSON object.  A JSON object maps from keys to
> > values, so we only need one.
> >
> > Your specification for  is wrong because it says that
> > it is a JSON array.  It is not.
> >
> > On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> > > Hello Ben,
> > >
> > > I have one more observation. I request you to please read it carefully.
> > If
> > > we go by the current monitor method definition, there can be only
> > > 
> > > in one monitor RPC method. If it is expected to have only one
> > > 
> > > i.e. one table and an array of , then the current
> > > specification is good.
> > >
> > > o  "method": "monitor"
> > >
> > > o  "params": [, , ]
> > >
> > > o  "id": 
> > >
> > >
> > > However, if it is possible to specify multiple table monitoring in one
> > RPC
> > > method, IMHO the above syntax would change as below.
> > >
> > >
> > > o  "method": "monitor"
> > >
> > > o  "params": [, , *]
> > >
> > > o  "id": 
> > >
> > >
> > > For completeness, I am also specifying the syntax for .
> > >
> > > monitor-requests : [, *]
> > >
> > >
> > > Let me know if this would be correct or if you think otherwise.
> > >
> > > /anil.
> > >
> > >
> > >
> > > On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff  wrote:
> > >
> > > > Ah, OK, you're saying that there's a missing [] around the
> > > > .  This goes back to a change that we made to the
> > > > ovsdb-server protocol a long time ago to allow multiple
> > > >  objects instead of just a single one.  ovsdb-server
> > > > still supports this form.  You can see this documented in
> > > > Documentation/ref/ovsdb-server.7.rst:
> > > >
> > > > For backward compatibility, ``ovsdb-server`` currently permits a
> > single
> > > >  to be used instead of an array; it is treated as
> > a
> > > > single-element array.  Future versions of ``ovsdb-server`` might
> > > > remove this
> > > > compatibility feature.
> > > >
> > > > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> > > >
> > > > Anyway, that's easy enough, so I sent a patch:
> > > > https://patchwork.ozlabs.org/patch/882710/
> > > >
> > > > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > > > Hello Ben,
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > >
> > > > >
> > > > > As the  maps the table name to be monitored to an
> > array
> > > > > of , my interpretation of it is as "Table Name <-->
> > > > Array
> > > > > of "
> > > > >
> > > > > I am giving an example message is given below.
> > > > >
> > > > > {
> > > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > > >   "method": "monitor",
> > > > >   "params": [
> > > > > "hardware_vtep",
> > > > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > > {
> > > > >   "Physical_Locator": [
> > > > > {
> > > > >   "columns": [
> > > > > "dst_ip",
> > > > > "encapsulation_type",
> > > > > "_uuid"
> > > > >   ],
> > > > >   "select": {
> > > > > "initial": true,
> > > > > "insert": true,
> > > > > "delete": true,
> > > > > "modify": true
> > > > >   }
> > > > > },
> > > > > {
> > > > >   "columns": [
> > > > > "_uuid",
> > > > > "locators"
> > > > >   ],
> > > > >   "select": {
> > > > > "initial": true,
> > > > > "insert": true,
> > > > > "delete": true,
> > > > > "modify": true
> > > > >   }
> > > > > }
> > > > >   ]
> > > > > }
> > > > >   ]
> > > > > }
> > > > >
> > > > >
> > > > > /anil.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff  wrote:
> > > > >
> > > > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > The RFC7047 states below about the Monitor request.
> > > > > > >
> > > > > > > The request object has the
> > > > > > >
> > > > > > >following members:
> > > > > > >
> > > > > > >o  "method": "monitor"
> > > > > > >
> > > > > > >o  "params": [, , ]
> > > > > > >
> > > > > > >o  "id": 
> > > > > > >
> > > > > > >
> > > > > > > The  parameter is used to match subsequent update
> > > > > > >
> > > > > > > notifications (see below) to this request.
> > > > > > >
> > > > > > >
> > > > > > > The  object maps the name of the table to be
> > > > monitored
> > >

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Anil Jangam]

Thanks Ben for clarification. So it means one Monitor request can request
for only one Table monitoring, correct?

On Thu, Mar 8, 2018 at 10:36 AM, Ben Pfaff  wrote:

>  is a JSON object.  A JSON object maps from keys to
> values, so we only need one.
>
> Your specification for  is wrong because it says that
> it is a JSON array.  It is not.
>
> On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> > Hello Ben,
> >
> > I have one more observation. I request you to please read it carefully.
> If
> > we go by the current monitor method definition, there can be only
> > 
> > in one monitor RPC method. If it is expected to have only one
> > 
> > i.e. one table and an array of , then the current
> > specification is good.
> >
> > o  "method": "monitor"
> >
> > o  "params": [, , ]
> >
> > o  "id": 
> >
> >
> > However, if it is possible to specify multiple table monitoring in one
> RPC
> > method, IMHO the above syntax would change as below.
> >
> >
> > o  "method": "monitor"
> >
> > o  "params": [, , *]
> >
> > o  "id": 
> >
> >
> > For completeness, I am also specifying the syntax for .
> >
> > monitor-requests : [, *]
> >
> >
> > Let me know if this would be correct or if you think otherwise.
> >
> > /anil.
> >
> >
> >
> > On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff  wrote:
> >
> > > Ah, OK, you're saying that there's a missing [] around the
> > > .  This goes back to a change that we made to the
> > > ovsdb-server protocol a long time ago to allow multiple
> > >  objects instead of just a single one.  ovsdb-server
> > > still supports this form.  You can see this documented in
> > > Documentation/ref/ovsdb-server.7.rst:
> > >
> > > For backward compatibility, ``ovsdb-server`` currently permits a
> single
> > >  to be used instead of an array; it is treated as
> a
> > > single-element array.  Future versions of ``ovsdb-server`` might
> > > remove this
> > > compatibility feature.
> > >
> > > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> > >
> > > Anyway, that's easy enough, so I sent a patch:
> > > https://patchwork.ozlabs.org/patch/882710/
> > >
> > > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > > Hello Ben,
> > > >
> > > > The  object maps the name of the table to be
> monitored
> > > >
> > > > to an array of  objects. Each  is
> an
> > > >
> > > > object with the following members:
> > > >
> > > >"columns": [*]optional
> > > >
> > > >"select": optional
> > > >
> > > >
> > > >
> > > > As the  maps the table name to be monitored to an
> array
> > > > of , my interpretation of it is as "Table Name <-->
> > > Array
> > > > of "
> > > >
> > > > I am giving an example message is given below.
> > > >
> > > > {
> > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > >   "method": "monitor",
> > > >   "params": [
> > > > "hardware_vtep",
> > > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > {
> > > >   "Physical_Locator": [
> > > > {
> > > >   "columns": [
> > > > "dst_ip",
> > > > "encapsulation_type",
> > > > "_uuid"
> > > >   ],
> > > >   "select": {
> > > > "initial": true,
> > > > "insert": true,
> > > > "delete": true,
> > > > "modify": true
> > > >   }
> > > > },
> > > > {
> > > >   "columns": [
> > > > "_uuid",
> > > > "locators"
> > > >   ],
> > > >   "select": {
> > > > "initial": true,
> > > > "insert": true,
> > > > "delete": true,
> > > > "modify": true
> > > >   }
> > > > }
> > > >   ]
> > > > }
> > > >   ]
> > > > }
> > > >
> > > >
> > > > /anil.
> > > >
> > > >
> > > >
> > > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff  wrote:
> > > >
> > > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > > Hi,
> > > > > >
> > > > > > The RFC7047 states below about the Monitor request.
> > > > > >
> > > > > > The request object has the
> > > > > >
> > > > > >following members:
> > > > > >
> > > > > >o  "method": "monitor"
> > > > > >
> > > > > >o  "params": [, , ]
> > > > > >
> > > > > >o  "id": 
> > > > > >
> > > > > >
> > > > > > The  parameter is used to match subsequent update
> > > > > >
> > > > > > notifications (see below) to this request.
> > > > > >
> > > > > >
> > > > > > The  object maps the name of the table to be
> > > monitored
> > > > > >
> > > > > > to an array of  objects. Each 
> is
> > > an
> > > > > >
> > > > > > object with the following members:
> > > > > >
> > > > > >"columns": [*]optional
> > > > > >
> > > > > >"select": optional
> > > > > >
> > > > > > The columns, if present, define the columns within the table to
> be
> > > > > monitored.
> > > > > >
> > > > > >  is an object with the following members:
> > > > > >
> > > > > 

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

 is a JSON object.  A JSON object maps from keys to
values, so we only need one.

Your specification for  is wrong because it says that
it is a JSON array.  It is not.

On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> Hello Ben,
> 
> I have one more observation. I request you to please read it carefully. If
> we go by the current monitor method definition, there can be only
> 
> in one monitor RPC method. If it is expected to have only one
> 
> i.e. one table and an array of , then the current
> specification is good.
> 
> o  "method": "monitor"
> 
> o  "params": [, , ]
> 
> o  "id": 
> 
> 
> However, if it is possible to specify multiple table monitoring in one RPC
> method, IMHO the above syntax would change as below.
> 
> 
> o  "method": "monitor"
> 
> o  "params": [, , *]
> 
> o  "id": 
> 
> 
> For completeness, I am also specifying the syntax for .
> 
> monitor-requests : [, *]
> 
> 
> Let me know if this would be correct or if you think otherwise.
> 
> /anil.
> 
> 
> 
> On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff  wrote:
> 
> > Ah, OK, you're saying that there's a missing [] around the
> > .  This goes back to a change that we made to the
> > ovsdb-server protocol a long time ago to allow multiple
> >  objects instead of just a single one.  ovsdb-server
> > still supports this form.  You can see this documented in
> > Documentation/ref/ovsdb-server.7.rst:
> >
> > For backward compatibility, ``ovsdb-server`` currently permits a single
> >  to be used instead of an array; it is treated as a
> > single-element array.  Future versions of ``ovsdb-server`` might
> > remove this
> > compatibility feature.
> >
> > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> >
> > Anyway, that's easy enough, so I sent a patch:
> > https://patchwork.ozlabs.org/patch/882710/
> >
> > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > Hello Ben,
> > >
> > > The  object maps the name of the table to be monitored
> > >
> > > to an array of  objects. Each  is an
> > >
> > > object with the following members:
> > >
> > >"columns": [*]optional
> > >
> > >"select": optional
> > >
> > >
> > >
> > > As the  maps the table name to be monitored to an array
> > > of , my interpretation of it is as "Table Name <-->
> > Array
> > > of "
> > >
> > > I am giving an example message is given below.
> > >
> > > {
> > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > >   "method": "monitor",
> > >   "params": [
> > > "hardware_vtep",
> > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > {
> > >   "Physical_Locator": [
> > > {
> > >   "columns": [
> > > "dst_ip",
> > > "encapsulation_type",
> > > "_uuid"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > },
> > > {
> > >   "columns": [
> > > "_uuid",
> > > "locators"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > }
> > >   ]
> > > }
> > >   ]
> > > }
> > >
> > >
> > > /anil.
> > >
> > >
> > >
> > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff  wrote:
> > >
> > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > Hi,
> > > > >
> > > > > The RFC7047 states below about the Monitor request.
> > > > >
> > > > > The request object has the
> > > > >
> > > > >following members:
> > > > >
> > > > >o  "method": "monitor"
> > > > >
> > > > >o  "params": [, , ]
> > > > >
> > > > >o  "id": 
> > > > >
> > > > >
> > > > > The  parameter is used to match subsequent update
> > > > >
> > > > > notifications (see below) to this request.
> > > > >
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > > The columns, if present, define the columns within the table to be
> > > > monitored.
> > > > >
> > > > >  is an object with the following members:
> > > > >
> > > > >"initial":   optional
> > > > >
> > > > >"insert":optional
> > > > >
> > > > >"delete":optional
> > > > >
> > > > >"modify":optional
> > > > >
> > > > > The contents of this object specify how the columns or table are to
> > be
> > > > > monitored,
> > > > >
> > > > > as explained in more detail below.
> > > > >
> > > > >
> > > > > However, when I look at some of the legitimate samples of the Monitor
> > > > > 

Re: [ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show

[Ben Pfaff]

On Thu, Mar 08, 2018 at 04:43:50PM +, Miguel Angel Ajo Pelayo wrote:
> Ok, looking at the code, it seems like we may only need to do this?
> 
> diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> index 21fa18d..2ac60bf 100644
> --- a/utilities/ovs-vsctl.c
> +++ b/utilities/ovs-vsctl.c
> @@ -1018,7 +1018,9 @@ static struct cmd_show_table cmd_show_tables[] = {
>   &ovsrec_interface_col_name,
>   {&ovsrec_interface_col_type,
>&ovsrec_interface_col_options,
> -  &ovsrec_interface_col_error},
> +  &ovsrec_interface_col_error,
> +  &ovsrec_interface_col_bfd,
> +  &ovsrec_interface_col_bfd_status},
>   {NULL, NULL, NULL}
>  },

Yes, you also need to increase the size of columns[] in cmd_show_table:

diff --git a/lib/db-ctl-base.h b/lib/db-ctl-base.h
index eb444270535b..5d8532a7bde2 100644
--- a/lib/db-ctl-base.h
+++ b/lib/db-ctl-base.h
@@ -197,7 +197,7 @@ struct weak_ref_table {
 struct cmd_show_table {
 const struct ovsdb_idl_table_class *table;
 const struct ovsdb_idl_column *name_column;
-const struct ovsdb_idl_column *columns[3]; /* Seems like a good number. */
+const struct ovsdb_idl_column *columns[5]; /* Seems like a good number. */
 const struct weak_ref_table wref_table;
 };
 
> But that would render something like:
> 
> 
> [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
> 5f35518a-ab34-49a4-a227-e487e251b7e3
> Manager "ptcp:6640:127.0.0.1"
> is_connected: true
> Bridge br-int
> fail_mode: secure
> Port "ovn-14d60a-0"
> Interface "ovn-14d60a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.12"}
> bfd: {enable="true"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> 
> 
> I'm partly guessing here based on what I see around lib/db-ctl-base.c and
> doing a little bit of debugging.
> 
> @Ben is there any way of filtering out those columns when
> bfd:enabled="false" or not set ?

It appears that that's already what happens, at least for the "not set"
case.  I doubt there are many controllers that explicitly set enable to
false.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Passive openflow proxy

[Ben Pfaff]

On Thu, Mar 08, 2018 at 07:51:23PM +0800, Xiao Liang wrote:
> In my experience, one thing I feel inconvenient is that some switches
> don't support controller-initiated connections. It would be helpful
> for testing and debugging if ovs-ofctl could be used.
> I'd propose an openflow proxy which is responsible for accepting and
> maintaining connections from switches, opening sockets for controllers
> to connect, and proxy messages between them. So that openflow tools
> like ovs-ofctl can operate on these switches.
> Another approach might be adding a "passive mode" to ovs-ofctl, which
> listens for connections, and opens an interactive shell to run
> commands.

I guess that this is a problem with non-OVS switches?  OVS does support
controller-initiated connections.

The proxy that you describe is going to be difficult to write because to
be most useful it would have to multiplex multiple connections into a
single connection.  OpenFlow connections are not stateless, so it would
have to figure out how to effectively partition the desires of multiple
clients into a single session.  I haven't thought through all the
necessary logic, but it would not be trivial.

I think that the ovs-ofctl passive mode that you describe is similar in
practice to writing a proxy: probably, it would internally start a proxy
and then allow the user to access it.  It might be easiest to actually
implement it as a mode for the proxy that starts a subshell.

I think that this is a worthy project, for someone for whom support for
non-OVS switches is important, and I'd encourage a motivated developer
to work on it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser interface.

[Anirudh Chanagiri]

Hi Ian,
We are using libvirt. I just checked by following the steps. But still we are 
facing the same issue.
Attaching the XML.
Thank you.
Regards
Anirudh
From: "Stokes, Ian" mailto:ian.sto...@intel.com>>
Date: Thursday, March 8, 2018 at 8:02 PM
To: Anirudh Chanagiri 
mailto:anirudh.chanag...@riverbed.com>>, 
"disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>
Cc: Pillalamarri Bala Venkata Ramana 
mailto:ramana.pillalama...@riverbed.com>>, 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>, 
"Corredor, Alejandro" 
mailto:alejandro.corre...@intel.com>>
Subject: RE: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Thanks,

I didn’t spot anything out of place in the logs.

Are you using QEMU or Libvirt to start the VM? If Qemu could you share the 
command used to launch the VM, if it’s libvirt can you confirm you’ve followed 
the steps for

http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#adding-vhost-user-ports-to-the-guest-libvirt

and share the xml your using for the VM.

Thanks
Ian


From: Anirudh Chanagiri [mailto:anirudh.chanag...@riverbed.com]
Sent: Wednesday, March 7, 2018 6:21 AM
To: Stokes, Ian mailto:ian.sto...@intel.com>>; 
disc...@openvswitch.org
Cc: Ramana Pillalamarri 
mailto:ramana.pillalama...@riverbed.com>>; 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>; 
Corredor, Alejandro 
mailto:alejandro.corre...@intel.com>>
Subject: Re: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hi Ian,
Thanks a ton for looking into this.

Yes we still have the issue.
Attached the ovs log,

The QEMU version is
qemu-system-x86_64 --version
QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

Also we have put in all the steps we followed to create bridges and port in the 
attached file dpdk_cmd.
There was a suggestion from someone in the  community to try compiling a stable 
version from source, we did that but that but ran into some issues with that.

My guess is we are missing some configuration which we are not able to figure 
out, since we encountered the same problems with different kernel/ DPDK/OVS 
versions.
That’s why have attached the dpdk_cmd file so that any config related issues 
could be identified.
Regards
Anirudh


From: "Stokes, Ian" mailto:ian.sto...@intel.com>>
Date: Tuesday, March 6, 2018 at 6:15 PM
To: Anirudh Chanagiri 
mailto:anirudh.chanag...@riverbed.com>>, 
"disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>
Cc: Pillalamarri Bala Venkata Ramana 
mailto:ramana.pillalama...@riverbed.com>>, 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>, 
"Corredor, Alejandro" 
mailto:alejandro.corre...@intel.com>>
Subject: RE: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hi Anirudh,

Is this still an issue for you?

I tried recreating the issue on my own system following your setup steps but I 
did not encounter any issue, I was able to ping both the OVS bridge and 
external VMs  using vhostuser.

If this is still an issue could your provide the OVS logs for you system when 
the problem occurs.

Also the version of QEMU you are using in the host along with any setup steps 
you perform in the guest would be useful for debugging.

Thanks
Ian


From:ovs-discuss-boun...@openvswitch.org
 [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Anirudh Chanagiri
Sent: Thursday, February 22, 2018 5:31 AM
To: b...@openvswitch.org
Cc: Ramana Pillalamarri 
mailto:ramana.pillalama...@riverbed.com>>; 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>; 
Corredor, Alejandro 
mailto:alejandro.corre...@intel.com>>
Subject: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hello everyone,
We are having some  issues using ovs-dpdk with vhostuser interface,
Seeking your help on the same.

Description of the issue :

Setup Details:
  1.  Host is  an Ubuntu 17.04.
  2.  We have created an open OVS switch with 2 arms  , one arm of the switch 
is physical interface which is given to DPDK driver and the the other arm is 
the dpdkvhostuser interface, which is given to an ubuntu 16.04 VM.
  3.  Inside the Ubuntu VM , we are not running  any DPDK based application.
  4.  We just want to check the connectivity of the guest VM to the outside 
world using DPDK-OVS

Version details:
1.  Open v switch version.
ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.8.0
2. Guest Ubuntu 16.04,  Kernel version 4.4.0-62-generic
3.  Host  Ubuntu 17.04, Kernel version 4.13.0-32-generic
4. DPDK version 17.05.2



   Problem description:
We are unable to have connectivity to/from the VM  using OVS-DPDK vhostuser 
interface.

1.  If we assign an ip to the OVS bridge and try pinging it, even that doesn’t 

Re: [ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show

[Miguel Angel Ajo Pelayo]

Ok, looking at the code, it seems like we may only need to do this?

diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
index 21fa18d..2ac60bf 100644
--- a/utilities/ovs-vsctl.c
+++ b/utilities/ovs-vsctl.c
@@ -1018,7 +1018,9 @@ static struct cmd_show_table cmd_show_tables[] = {
  &ovsrec_interface_col_name,
  {&ovsrec_interface_col_type,
   &ovsrec_interface_col_options,
-  &ovsrec_interface_col_error},
+  &ovsrec_interface_col_error,
+  &ovsrec_interface_col_bfd,
+  &ovsrec_interface_col_bfd_status},
  {NULL, NULL, NULL}
 },


But that would render something like:


[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
5f35518a-ab34-49a4-a227-e487e251b7e3
Manager "ptcp:6640:127.0.0.1"
is_connected: true
Bridge br-int
fail_mode: secure
Port "ovn-14d60a-0"
Interface "ovn-14d60a-0"
type: geneve
options: {csum="true", key=flow, remote_ip="172.16.0.12"}
bfd: {enable="true"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1",
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
state=up}


I'm partly guessing here based on what I see around lib/db-ctl-base.c and
doing a little bit of debugging.

@Ben is there any way of filtering out those columns when
bfd:enabled="false" or not set ?

Thanks in advance,
Miguel Ángel.

On Wed, Mar 7, 2018 at 10:04 PM Anil Venkata  wrote:

> This is nice option to have.
>
> On 07-Mar-2018 6:27 PM, "Miguel Angel Ajo Pelayo" 
> wrote:
>
>>
>> As OVN started implementing L3HA with the use of BFD monitoring, after
>> discussing with the people who is doing QA and thinking about future
>> troubleshooting of the feature, they proposed something the thing on
>> $subject.
>>
>> What do you think?
>>
>> For example, in this case:
>>
>> [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl list Interface |
>> grep -E "bfd |name |bfd_status"
>> bfd : {}
>> bfd_status  : {}
>> name: "tapc6eed125-08"
>> bfd : {enable="true"}
>> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>> name: "ovn-e4dd7a-0"
>> bfd : {enable="true"}
>> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>> name: "ovn-14d60a-0"
>> bfd : {}
>> bfd_status  : {}
>> name: br-ex
>> bfd : {}
>> bfd_status  : {}
>> name: "vlan30"
>> bfd : {}
>> bfd_status  : {}
>> name: br-int
>> bfd : {}
>> bfd_status  : {}
>> name: "vlan20"
>> bfd : {}
>> bfd_status  : {}
>> name: "tapd09b3382-50"
>> bfd : {}
>> bfd_status  : {}
>> name: "vlan50"
>> bfd : {}
>> bfd_status  : {}
>> name: "eth0"
>> bfd : {enable="true"}
>> bfd_status  : {diagnostic="No Diagnostic", flap_count="1",
>> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
>> state=up}
>> name: "ovn-c8b85a-0"
>>
>>
>> It could look like:
>>
>> [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
>> 5f35518a-ab34-49a4-a227-e487e251b7e3
>> Manager "ptcp:6640:127.0.0.1"
>> is_connected: true
>> Bridge br-int
>> fail_mode: secure
>> Port "ovn-14d60a-0"
>> Interface "ovn-14d60a-0"
>> type: geneve
>> options: {csum="true", key=flow, remote_ip="172.16.0.12"}
>>   *  bfd: {remote_state="up", state="up", flap_count="1"}*
>> Port "ovn-e4dd7a-0"
>> Interface "ovn-e4dd7a-0"
>> type: geneve
>> options: {csum="true", key=flow, remote_ip="172.16.0.22"}
>>* bfd: {remote_state="up", state="up", flap_count="1"}*
>> Port br-int
>> Interface br-int
>> type: internal
>> Port "tapd09b3382-50"
>> Interface "tapd09b3382-50"
>> Port "tapc6eed125-08"
>> Interface "tapc6eed125-08"
>> Port "ovn-c8b85a-0"
>> Interface "ovn-c8b85a-0"
>> type: geneve
>> options: {csum="true", key=flow, remote_ip="172.16.0.17"}
>> *bfd: {remote_state="up", state="up", flap_count="1"}*
>> Bridge br-ex
>> fail_mode: standalone
>> Port "vlan30"
>> tag: 30
>> Interface "vlan30"
>> type: internal
>> Port br-ex
>> Interface br-ex
>> type: internal
>> Port "eth0"
>> Interface "eth0"
>> Port "vlan

Re: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser interface.

[Stokes, Ian]

Thanks,

I didn't spot anything out of place in the logs.

Are you using QEMU or Libvirt to start the VM? If Qemu could you share the 
command used to launch the VM, if it's libvirt can you confirm you've followed 
the steps for

http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#adding-vhost-user-ports-to-the-guest-libvirt

and share the xml your using for the VM.

Thanks
Ian


From: Anirudh Chanagiri [mailto:anirudh.chanag...@riverbed.com]
Sent: Wednesday, March 7, 2018 6:21 AM
To: Stokes, Ian ; disc...@openvswitch.org
Cc: Ramana Pillalamarri ; Siddharth Mundle 
; Corredor, Alejandro 

Subject: Re: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hi Ian,
Thanks a ton for looking into this.

Yes we still have the issue.
Attached the ovs log,

The QEMU version is
qemu-system-x86_64 --version
QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

Also we have put in all the steps we followed to create bridges and port in the 
attached file dpdk_cmd.
There was a suggestion from someone in the  community to try compiling a stable 
version from source, we did that but that but ran into some issues with that.

My guess is we are missing some configuration which we are not able to figure 
out, since we encountered the same problems with different kernel/ DPDK/OVS 
versions.
That's why have attached the dpdk_cmd file so that any config related issues 
could be identified.
Regards
Anirudh


From: "Stokes, Ian" mailto:ian.sto...@intel.com>>
Date: Tuesday, March 6, 2018 at 6:15 PM
To: Anirudh Chanagiri 
mailto:anirudh.chanag...@riverbed.com>>, 
"disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>
Cc: Pillalamarri Bala Venkata Ramana 
mailto:ramana.pillalama...@riverbed.com>>, 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>, 
"Corredor, Alejandro" 
mailto:alejandro.corre...@intel.com>>
Subject: RE: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hi Anirudh,

Is this still an issue for you?

I tried recreating the issue on my own system following your setup steps but I 
did not encounter any issue, I was able to ping both the OVS bridge and 
external VMs  using vhostuser.

If this is still an issue could your provide the OVS logs for you system when 
the problem occurs.

Also the version of QEMU you are using in the host along with any setup steps 
you perform in the guest would be useful for debugging.

Thanks
Ian


From: 
ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Anirudh Chanagiri
Sent: Thursday, February 22, 2018 5:31 AM
To: b...@openvswitch.org
Cc: Ramana Pillalamarri 
mailto:ramana.pillalama...@riverbed.com>>; 
Siddharth Mundle 
mailto:siddharth.mun...@riverbed.com>>; 
Corredor, Alejandro 
mailto:alejandro.corre...@intel.com>>
Subject: [ovs-discuss] Facing issues while using OVS-DPDK based vhostuser 
interface.

Hello everyone,
We are having some  issues using ovs-dpdk with vhostuser interface,
Seeking your help on the same.

Description of the issue :

Setup Details:
  1.  Host is  an Ubuntu 17.04.
  2.  We have created an open OVS switch with 2 arms  , one arm of the switch 
is physical interface which is given to DPDK driver and the the other arm is 
the dpdkvhostuser interface, which is given to an ubuntu 16.04 VM.
  3.  Inside the Ubuntu VM , we are not running  any DPDK based application.
  4.  We just want to check the connectivity of the guest VM to the outside 
world using DPDK-OVS

Version details:
1.  Open v switch version.
ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.8.0
2. Guest Ubuntu 16.04,  Kernel version 4.4.0-62-generic
3.  Host  Ubuntu 17.04, Kernel version 4.13.0-32-generic
4. DPDK version 17.05.2



   Problem description:
We are unable to have connectivity to/from the VM  using OVS-DPDK vhostuser 
interface.

1.  If we assign an ip to the OVS bridge and try pinging it, even that doesn't 
work.
2.  If use a tun/tap interface instead of dpdkvhostuser interface the 
connectivity works fine. So the issue is specific to dpdkvhostuser interface.

Seeking your help to resolve the same.
Attaching the output of some useful commands and a setup diagram.

Regards,
Anirudh

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

Re: [ovs-discuss] segmentation fault when adding a VF in DPDK to a switch

[Stokes, Ian]

Hi Riccardo,

So the issue you are seeing is not related to the VSI queue setup as previously 
mentioned. The issue you see is specific to the use of the i350 VF with OVS it 
seems.

Specifically, OVS attempts to set the MTU of a given device (in this case the 
SRIOV VF from an i350 interface known as igbvf) with the call

diag = rte_eth_dev_set_mtu(dev->port_id, dev->mtu);

Currently igbvf devices do not support rte_eth_dev_set_mtu. This is confirmed 
upon examination of the igbvf operations in DPDK (note mtu_set = 0x0 below)

$1 = {dev_configure = 0x5326e1 , dev_start = 0x532772 
, dev_stop = 0x532980 , dev_set_link_up = 0x0, 
dev_set_link_down = 0x0, dev_close = 0x532a34 ,  dev_reset = 
0x0, link_update = 0x530bf1 , promiscuous_enable = 
0x532abe , promiscuous_disable = 0x532aee 
,
  allmulticast_enable = 0x532b47 , 
allmulticast_disable = 0x532b8d , mac_addr_remove = 
0x0, mac_addr_add = 0x0, mac_addr_set = 0x532e4d ,  
set_mc_addr_list = 0x535ca2 , mtu_set = 0x0, 
stats_get = 0x5303e5 , stats_reset = 0x530488 
, xstats_get = 0x53030f ,  
xstats_reset = 0x530488 , xstats_get_names = 0x530299 
, queue_stats_mapping_set = 0x0, dev_infos_get = 
0x5309cf , rxq_info_get = 0x53f4b2 ,  
txq_info_get = 0x53f53f , fw_version_get = 0x0, 
dev_supported_ptypes_get = 0x53099b , 
vlan_filter_set = 0x532d4b , vlan_tpid_set = 0x0,  
vlan_strip_queue_set = 0x0, vlan_offload_set = 0x0, vlan_pvid_set = 0x0, 
rx_queue_start = 0x0, rx_queue_stop = 0x0, tx_queue_start = 0x0, tx_queue_stop 
= 0x0, rx_queue_setup = 0x53c42c ,  rx_queue_release = 
0x53c39f , rx_queue_count = 0x0, rx_descriptor_done = 
0x0, rx_descriptor_status = 0x0, tx_descriptor_status = 0x0, 
rx_queue_intr_enable = 0x0, rx_queue_intr_disable = 0x0,  tx_queue_setup = 
0x53bbb1 , tx_queue_release = 0x53b42c 
, tx_done_cleanup = 0x0, dev_led_on = 0x0, 
dev_led_off = 0x0, flow_ctrl_get = 0x0, flow_ctrl_set = 0x0,  
priority_flow_ctrl_set = 0x0, uc_hash_table_set = 0x0, uc_all_hash_table_set = 
0x0, mirror_rule_set = 0x0, mirror_rule_reset = 0x0, udp_tunnel_port_add = 0x0, 
udp_tunnel_port_del = 0x0, l2_tunnel_eth_type_conf = 0x0,  
l2_tunnel_offload_set = 0x0, set_queue_rate_limit = 0x0, rss_hash_update = 0x0, 
rss_hash_conf_get = 0x0, reta_update = 0x0, reta_query = 0x0, get_reg = 
0x536a60 , get_eeprom_length = 0x0, get_eeprom = 0x0,  
set_eeprom = 0x0, filter_ctrl = 0x0, get_dcb_info = 0x0, timesync_enable = 0x0, 
timesync_disable = 0x0, timesync_read_rx_timestamp = 0x0, 
timesync_read_tx_timestamp = 0x0, timesync_adjust_time = 0x0, 
timesync_read_time = 0x0,  timesync_write_time = 0x0, xstats_get_by_id = 0x0, 
xstats_get_names_by_id = 0x0, tm_ops_get = 0x0, mtr_ops_get = 0x0, 
pool_ops_supported = 0x0}

I confirmed this by also testing an i40evf device and in that case the mtu_set 
function is supported so I didn’t see the error/segfault you reported.

Support for rte_eth_dev_set_mtu was introduced in commit 
67fe6d635193761439f791e48652acfd60076cfb. The purpose was to set the mtu for 
the physical device so that call to rte_eth_dev_get_mtu() would correctly 
report the MTU set for the port. The best solution here would be for support to 
be introduced in DPDK for rte_eth_dev_set_mtu() for igbvf functions. However 
this will have to be in a future release and means you will be blocked until 
then.

For testing purposes you could re-introduce the previous method of setting the 
mtu for the device (Note this is compile tested only):

+
+/*
+ * Need to enable hw_strip_crc specifically for SRIOV devices.
+ */
+conf.rxmode.hw_strip_crc = 1;
+
 /* A device may report more queues than it makes available (this has
  * been observed for Intel xl710, which reserves some of them for
  * SRIOV):  rte_eth_*_queue_setup will fail if a queue is not
@@ -718,11 +724,25 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int 
n_rxq, int n_txq)
 }

 diag = rte_eth_dev_set_mtu(dev->port_id, dev->mtu);
-if (diag) {
+if (diag && (diag != -ENOTSUP)) {
 VLOG_ERR("Interface %s MTU (%d) setup error: %s",
 dev->up.name, dev->mtu, rte_strerror(-diag));
 break;
 }
+else {
+/* Some devices do not support rte_eth_dev_set_mtu e.g. igbvf.
+ * If the operation is not supported attempt to set MTU manually
+ * in the devices configuration.
+ */
+if (dev->mtu > ETHER_MTU) {
+conf.rxmode.jumbo_frame = 1;
+conf.rxmode.max_rx_pkt_len = dev->max_packet_len;
+} else {
+conf.rxmode.jumbo_frame = 0;
+conf.rxmode.max_rx_pkt_len = 0;
+}
+diag = 0;
+}

This is not a pretty approach but might enable you to test further with the 
igbvf function in the meantime.

As regards the segfault occurring, in this case it was due to the error code 
returned when rte_eth_dev_set_mtu is not supported. The error code returned by 
DPDK

[ovs-discuss] OVS DPDK performance

[Ceco]

Hi all
I have a question about a performance in a specific use case, and any
suggestions  how to improve it. Use case:
Host runs Fedora 23, with kernel 4.4,  ovs 2.7.2 and dpdk 16.11. There are
few interfaces: first one does not support DPDK, all others support it.
Tested topology:
port 1 ---> ovs bridge 1 ---> VM ---> ovs bridge 2 ---> port 2
Traffic is unidirectional, from port 1 to port 2. Tested with 1500byte
packets. When port 1 and port 2 are configured in default (virtio) mode,
the throughput is ~500Mbps. If port 1 is in the same virtio mode, but port
2 is configured in DPDK (with datapath_type netdev), the max throughput is
~25Mbps. Noted that the packet size does not matter (checked with 64byte
packets),  in "bad" case it can process up to 2200 pps.

Any ideas how to improve the performance in the "bad" use case scenario. I
need to run in DPDK all interfaces, which support it.
If I switch to latest ovs (2.9) and dpdk, will it improve the performance -
are there any fixes related to this ?

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

[ovs-discuss] Passive openflow proxy

[Xiao Liang]

Hi all,

In my experience, one thing I feel inconvenient is that some switches
don't support controller-initiated connections. It would be helpful
for testing and debugging if ovs-ofctl could be used.
I'd propose an openflow proxy which is responsible for accepting and
maintaining connections from switches, opening sockets for controllers
to connect, and proxy messages between them. So that openflow tools
like ovs-ofctl can operate on these switches.
Another approach might be adding a "passive mode" to ovs-ofctl, which
listens for connections, and opens an interactive shell to run
commands.

Any ideas?

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

[ovs-discuss] latest 2.9 geneve/stt tunnel adds a drop flow for src and dst

[aginwala]

When setting up central node on a BM with latest ovs 2.9 on ubuntu 16.04
with any tunnel type(stt/geneve), there is tunnel port not found warning on
the central node along with drop flows for the guest vms due to which vms
cannot ping each other via tunnel.

ovn-nbctl show
switch a4ff74cb-540f-4347-a4ad-decb42b5 (ls1)
port lsp2
addresses: ["52:54:00:bc:7f:37 10.0.0.12"]
port lsp1
addresses: ["52:54:00:bb:7f:38 10.0.0.11"]

e.g.
When VM1 on HV1(+controller) associated to lsp1,  pings VM2 associated to
lsp2 on HV2 and vice versa.  virsh destroy and redefining the vms didn't
help which recreated the port on br-int.


Below *vswitchd logs* are populated on central node:

2018-03-08T07:55:55.819Z|00018|ofproto_dpif_upcall(handler106)|INFO|received
packet on unassociated datapath port 3
2018-03-08T07:56:55.277Z|00019|tunnel(handler106)|WARN|Dropped 118 log
messages in last 60 seconds (most recently, 1 seconds ago) due to excessive
rate
2018-03-08T07:56:55.277Z|00020|tunnel(handler106)|WARN|receive tunnel port
not found
(icmp,tun_id=0x1,tun_src=10.99.155.34,tun_dst=10.99.152.95,tun_ipv6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=0,tun_ttl=64,tun_flags=csum|key,in_port=3,vlan_tci=0x,dl_src=52:54:00:bc:7f:37,dl_dst=52:54:00:bb:7f:38,nw_src=10.0.0.12,nw_dst=10.0.0.11,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=8,icmp_code=0)


*ovs-appctl dpctl/show*
system@ovs-system:
lookups: hit:223 missed:423 lost:0
flows: 1
masks: hit:400 total:1 hit/pkt:0.62
port 0: ovs-system (internal)
port 1: br-int (internal)
port 2: vnet0
port 3: genev_sys_6081 (geneve:* packet_type=ptap*)

*ovs-dpctl dump-flows*
recirc_id(0),dp_hash(0),skb_priority(0),tunnel(tun_id=0x1,src=10.99.155.34,dst=10.99.152.95,ttl=64,tp_src=13361,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x20001}),flags(+csum+key)),in_port(3),skb_mark(0),ct_state(-new-est-rel-rpl-inv-trk-snat-dnat),ct_zone(0),ct_mark(0),ct_label(0),eth(src=52:54:00:bc:7f:37,dst=52:54:00:bb:7f:38),eth_type(0x0800),ipv4(src=10.0.0.12,dst=10.0.0.11,proto=1,tos=0,ttl=64,frag=no),icmp(type=8/0x8),
packets:0, bytes:0, used:never, *actions:drop*


So I did the following:
1. deleted flows using ovs-dpctl del-flows
2. ifconfig genev_sys_6081 down which is anyways tunnel port .
3. Restarted ovn-controllers on both HVs and the connectivity restored.



Below is the log of *vswitchd* after connectivity is restored:
0:00:00:00:00:00),
actions:set(tunnel(tun_id=0x1,dst=10.99.155.34,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x1}),flags(df|csum|key))),3
2018-03-08T08:54:49.940Z|00078|bridge|INFO|bridge br-int: deleted interface
ovn-503634-0 on port 8
2018-03-08T08:54:49.940Z|5|dpif(revalidator160)|WARN|system@ovs-system:
failed to put[modify] (No such file or directory)
ufid:00a1d729-ba1e-426f-bc4e-07bc8176b02f
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=52:54:00:bb:7f:38/01:00:00:00:00:00,dst=ff:ff:ff:ff:ff:ff/01:00:00:00:00:00),eth_type(0x0806),arp(sip=
10.0.0.11/0.0.0.0,tip=10.0.0.1,op=1/0xff,sha=52:54:00:bb:7f:38/00:00:00:00:00:00,tha=00:00:00:00:00:00/00:00:00:00:00:00
)
2018-03-08T08:54:49.962Z|3|dpif(revalidator156)|WARN|system@ovs-system:
failed to put[modify] (No such file or directory)
ufid:ee192376-7f15-4cef-91d5-01126d43394b
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=52:54:00:bb:7f:38,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.0.0.11,tip=10.0.0.12,op=1/0xff,sha=52:54:00:bb:7f:38,tha=00:00:00:00:00:00)
2018-03-08T08:54:49.992Z|00079|connmgr|INFO|br-int<->unix#25: 66 flow_mods
in the 9 s starting 10 s ago (61 adds, 5 deletes)
2018-03-08T08:54:50.048Z|00080|bridge|INFO|bridge br-int: added interface
ovn-503634-0 on port 9
2018-03-08T08:54:50.053Z|4|dpif(revalidator156)|WARN|system@ovs-system:
failed to put[modify] (No such file or directory)
ufid:ee192376-7f15-4cef-91d5-01126d43394b
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=52:54:00:bb:7f:38,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.0.0.11,tip=10.0.0.12,op=1/0xff,sha=52:54:00:bb:7f:38,tha=00:00:00:00:00:00),
actions:userspace(pid=4155565177,slow_path(action))
2018-03-08T08:54:50.053Z|6|dpif(revalidator160)|WARN|system@ovs-system:
failed to put[modify] (No such file or directory)
ufid:00a1d729-ba1e-426f-bc4e-07bc8176b02f
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(2),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=52:54:00:bb:7f:38/01:00:00:00:00:00,dst=ff:ff:ff:ff:ff:ff/01:00:00:00:00:00),eth_type(0x0806),arp(sip=
10.0.0.11/0.0.0.0,tip=10.0.0.1,op=1/0xff,sha=52:54:00:bb:7f:38/00:00:00:00:00:00,tha=00:00:00:00:00:00/00:00:00:00:00:00),
actions:set(tunnel(tun_id=0x1,dst=10.99.155.34,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x1}),flags(df|csum|ke

Re: [ovs-discuss] Problem on OpenVSwitch 2.9

[woz woz]

Dear Ben,

thanks for the support!

I receive the error on two servers C & D, below the command outputs:

[root@C ~]# ovs-dpctl show
system@ovs-system:
lookups: hit:283639 missed:348 lost:0
flows: 14
masks: hit:1027059 total:3 hit/pkt:3.62
port 0: ovs-system (internal)
port 1: ovsbr0 (internal)
port 2: enp4s0
port 3: tep0 (internal)
port 4: vxlan_sys_4789 (vxlan: packet_type=ptap)

[root@D ~]# ovs-dpctl show
system@ovs-system:
lookups: hit:230545 missed:378 lost:0
flows: 12
masks: hit:707437 total:2 hit/pkt:3.06
port 0: ovs-system (internal)
port 1: ovsbr0 (internal)
port 2: enp4s0
port 3: tep0 (internal)
port 4: vxlan_sys_4789 (vxlan: packet_type=ptap)

Thanks in advance,

Cheers,

Woz


On 7 March 2018 at 21:02, Ben Pfaff  wrote:

> On Wed, Mar 07, 2018 at 11:47:48AM +0100, woz woz wrote:
> > Dear support,
> > I’m testing OpenVSwitch version 2.9. on my infrastructure using CentOS7,
> > but I’m having any problem, below my config:
> > I have 4 servers with the public IP address, e.g.
> > A-> 1.1.1.1
> > B-> 2.2.2.2
> > C-> 3.3.3.3
> > D-> 4.4.4.4
> > between these servers I've configured a VXLAN tunnel, in this way :
> > the server named A has a VXLAN tunnel with C and D
> > the server named B has a VXLAN tunnel with C and D
> > the servers named C and D obviously have a tunnel with A and B
> > I executed this kind of configuration because I would like to have a
> > redundancy between the servers A and B , e.g if A goes down I migrate all
> > the services on B and the servers C and D can continue to work without
> any
> > problem.
> > But I have the following messages on the /var/log/message :
> > "kernel: openvswitch: ovs: recursion limit reached on datapath
> ovs-system,
> > probable configuration error”
> >
> > I 've read articles related to this kind of problem and I played also
> with
> > the STP protocol in order to avoid a possible loop but I don't understand
> > if I can use this configuration or I have to find another solution.
>
> This message wouldn't be caused by a loop among servers but some kind of
> configuration problem on an individual server.  When you see this
> message, what is in the kernel flow table ("ovs-dpctl dump-flows") and
> what ports are configured ("ovs-dpctl show")?
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss