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

[Anil Jangam]

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
> > > > requests, they are encoded as 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": 

[ovs-discuss] (no subject)

[???h????????]

My question is two: 1.ovs user state ping normal, but iperf is not normal, how 
to solve?
What are the functions supported by the 2.netdev type bridge?___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

No.  The "Reported-by:" tag is really just a kind of "thank-you".
Thanks again.

On Wed, Mar 07, 2018 at 02:50:32PM -0800, Anil Jangam wrote:
> Thanks you Ben! I saw the other patch email as well. Since it is says that
> "reported-by" me, do I have any further action item on me?
> 
> /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
> > > > > requests, they are encoded as 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
> > > > > }
> > > > >   

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

[Anil Jangam]

Thanks you Ben! I saw the other patch email as well. Since it is says that
"reported-by" me, do I have any further action item on me?

/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
> > > > requests, they are encoded as 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
> > > > }
> > > >   },
> > > >   "Physical_Locator_Set": {
> > > > "columns": [
> > > >   "_uuid",
> > > >   "locators"
> > > > ],
> > > > "select": {
> > > >   "initial": true,
> > > >   "insert": true,
> > > >   "delete": true,
> > > >   "modify": true
> > > > }
> > > >   }
> > > > }
> > > >   ]
> > > > }
> > > >
> > > >
> > > >
> > > > If we go by the RFC encoding rules, "params" contains the
> > > > , 

Re: [ovs-discuss] tap ports...

[Grant Taylor via discuss]

On 03/07/2018 12:56 PM, Ben Pfaff wrote:
Q: I created a tap device tap0, configured an IP address on it, and 
added it to a bridge, like this::


$ tunctl -t tap0
$ ip addr add 192.168.0.123/24 dev tap0
$ ip link set tap0 up
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 tap0

I expected that I could then use this IP address to contact other hosts 
on the network, but it doesn't work.  Why not?


This does not relate to my question any more than the term collisions of 
"tap" and "OVS".


A: The short answer is that this is a misuse of a "tap" device.  Use an 
internal" device implemented by Open vSwitch, which works differently 
and is designed for this use.  To solve this problem with an internal 
device, instead run:


I am quite happily using internal ports for VMs.

Internal ports will not work for thinks like OpenVPN User-Mode Linux.

Both OpenVPN and UML expect to open the unix socket file (descriptor) 
and receive Ethernet frames.  They do not work with a traditional 
network interface, like an OVS "internal" port.


Even more simply, you can take advantage of the internal port that every 
bridge has under the name of the bridge::


$ ovs-vsctl add-br br0
$ ip addr add 192.168.0.123/24 dev br0
$ ip link set br0 up


I agree with the statement, but it has no relation to my question.

In more detail, a "tap" device is an interface between the Linux (or BSD) 
network stack and a user program that opens it as a socket.


I'm very well aware of that.  That is the exact behavior that I'm wanting.

When the "tap" device transmits a packet, it appears in the socket opened 
by the userspace program.  Conversely, when the userspace program writes 
to the "tap" socket, the kernel TCP/IP stack processes the packet as if 
it had been received by the "tap" device.

That is exactly what my understanding of a tap interface is used for.

It's close cousin, the tun interface, behaves quite similar, save for 
the fact that it operates at layer 3 with IP packets between the 
interface and the unix socket.


Consider the configuration above.  Given this configuration, if you "ping" 
an IP address in the 192.168.0.x subnet, the Linux kernel routing stack 
will transmit an ARP on the tap0 device.


I would expect such transmitted ping (or more likely an associated ARP 
request) to come out the unix socket that a user space program like 
OpenVPN or UML would process.  -  Unrelated to my question.


Open vSwitch userspace treats "tap" devices just like any other network 
device; that is, it doesn't open them as "tap" sockets.


That's what I expected.


That means that the ARP packet will simply get dropped.


I'd think the dropping or not has more to do with what opens the tap's 
associated unix socket and very little to do with OVS.  -  In the case 
you are describing.


You might wonder why the Open vSwitch kernel module doesn't intercept the 
ARP packet and bridge it.


Nope, not at all.

After all, Open vSwitch intercepts packets on other devices.  The answer 
is that Open vSwitch only intercepts received packets, but this is a 
packet being transmitted.  The same thing happens for all other types 
of network devices, except for Open vSwitch "internal" ports.  If you, 
for example, add a physical Ethernet port to an OVS bridge, configure 
an IP address on a physical Ethernet port, and then issue a "ping" to an 
address in that subnet, the same thing happens: an ARP gets transmitted 
on the physical Ethernet port and Open vSwitch never sees it.


This is what I would expect.


(You should not do that, as documented at the beginning of this section.)


IMHO the start of your reply gave an example alternative example, and 
this paragraph confirmed what I expected would be the case.


However, that being said, I have had plenty of times that I have done 
this very thing with Linux kernel native bridges for various reasons. 
Frequently the service IP would live on a bridge and the maintenance IP 
(in a different subnet) lived on the underlying Ethernet interface.  It 
worked perfectly fine.  Granted, I had to be aware of the caveat that 
you outlined.  -  My point being, there are times when it is okay (maybe 
sub-optimal) to put an IP on a member interface instead of the bridge 
device itself.


It can make sense to add a "tap" device to an Open vSwitch bridge, if some 
userspace program (other than Open vSwitch) has opened the tap socket.


This is the EXACT type of scenario that I was asking about.  OpenVPN and 
UML (et al) opening the unix socket with their associated network 
interfaces connected to an OVS bridge.


This is the case, for example, if the "tap" device was created by KVM 
(or QEMU) to simulate a virtual NIC.  In such a case, when OVS bridges 
a packet to the "tap" device, the kernel forwards that packet to KVM in 
userspace, which passes it along to the VM, and in the other direction, 
when the VM sends a packet, KVM writes it to the "tap" socket, which 
causes OVS to 

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

[Anil Venkata]

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 "vlan50"
> tag: 50
> Interface "vlan50"
> type: internal
> Port "vlan20"
> tag: 20
> Interface "vlan20"
> type: internal
> ovs_version: "2.8.1"
>
> ___
> 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

[Ben Pfaff]

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] Including bfd status for tunnel endpoints on ovs-vsctl show

[Miguel Angel Ajo Pelayo]

I will submit it tomorrow, I wanted to share the idea first to make sure it
made sense.

Thank you,
Miguel Ángel.

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

> On Wed, Mar 07, 2018 at 12:56:49PM +, 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?
>
> Seems reasonable.  Do you want to submit a patch?
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Problem on OpenVSwitch 2.9

[Ben Pfaff]

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

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

[Daniel Alvarez Sanchez]

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] openvswitch userspace mode can not use iperf send packet，whatever tcp and udp

[Ben Pfaff]

On Tue, Mar 06, 2018 at 09:22:48AM +0800, ♂漢唐峻傑♀ wrote:
> ovs userspace mode how to install in centos7, datapath-type=netdev ，
> What does “netdev” stand for?

"network device"

> as well as with the meter table relation

I don't understand this question.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] tap ports...

[Ben Pfaff]

On Mon, Mar 05, 2018 at 10:31:30PM -0700, Grant Taylor via discuss wrote:
> Can OVS create tap ports like OpenVPN or KVM (Qemu) or User Mode Linux use?
> I.e. an Ethernet interface inside OVS and a socket that applications can
> glom onto and use.
> 
> I think I can create the tap interfaces manually (via tunctl or ip tuntap…)
> and then add them to a bridge.  However I feel like this is unnecessary and
> may very well be something that OVS can do without the separate devices.
> 
> Hence my question if OVS can create (internal) tap interfaces, much the same
> way that it can create (internal) vEth (like) interfaces.

Q: I created a tap device tap0, configured an IP address on it, and added it to
a bridge, like this::

$ tunctl -t tap0
$ ip addr add 192.168.0.123/24 dev tap0
$ ip link set tap0 up
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 tap0

I expected that I could then use this IP address to contact other hosts on the
network, but it doesn't work.  Why not?

A: The short answer is that this is a misuse of a "tap" device.  Use an
"internal" device implemented by Open vSwitch, which works differently and
is designed for this use.  To solve this problem with an internal device,
instead run::

$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
$ ip addr add 192.168.0.123/24 dev int0
$ ip link set int0 up

Even more simply, you can take advantage of the internal port that every
bridge has under the name of the bridge::

$ ovs-vsctl add-br br0
$ ip addr add 192.168.0.123/24 dev br0
$ ip link set br0 up

In more detail, a "tap" device is an interface between the Linux (or BSD)
network stack and a user program that opens it as a socket.  When the "tap"
device transmits a packet, it appears in the socket opened by the userspace
program.  Conversely, when the userspace program writes to the "tap"
socket, the kernel TCP/IP stack processes the packet as if it had been
received by the "tap" device.

Consider the configuration above.  Given this configuration, if you "ping"
an IP address in the 192.168.0.x subnet, the Linux kernel routing stack
will transmit an ARP on the tap0 device.  Open vSwitch userspace treats
"tap" devices just like any other network device; that is, it doesn't open
them as "tap" sockets.  That means that the ARP packet will simply get
dropped.

You might wonder why the Open vSwitch kernel module doesn't intercept the
ARP packet and bridge it.  After all, Open vSwitch intercepts packets on
other devices.  The answer is that Open vSwitch only intercepts *received*
packets, but this is a packet being transmitted.  The same thing happens
for all other types of network devices, except for Open vSwitch "internal"
ports.  If you, for example, add a physical Ethernet port to an OVS bridge,
configure an IP address on a physical Ethernet port, and then issue a
"ping" to an address in that subnet, the same thing happens: an ARP gets
transmitted on the physical Ethernet port and Open vSwitch never sees it.
(You should not do that, as documented at the beginning of this section.)

It can make sense to add a "tap" device to an Open vSwitch bridge, if some
userspace program (other than Open vSwitch) has opened the tap socket.
This is the case, for example, if the "tap" device was created by KVM (or
QEMU) to simulate a virtual NIC.  In such a case, when OVS bridges a packet
to the "tap" device, the kernel forwards that packet to KVM in userspace,
which passes it along to the VM, and in the other direction, when the VM
sends a packet, KVM writes it to the "tap" socket, which causes OVS to
receive it and bridge it to the other OVS ports.  Please note that in such
a case no IP address is configured on the "tap" device (there is normally
an IP address configured in the virtual NIC inside the VM, but this is not
visible to the host Linux kernel or to Open vSwitch).

There is one special case in which Open vSwitch does directly read and
write "tap" sockets.  This is an implementation detail of the Open vSwitch
userspace switch, which implements its "internal" ports as Linux (or BSD)
"tap" sockets.  In such a userspace switch, OVS receives packets sent on
the "tap" device used to implement an "internal" port by reading the
associated "tap" socket, and bridges them to the rest of the switch.  In
the other direction, OVS transmits packets bridged to the "internal" port
by writing them to the "tap" socket, causing them to be processed by the
kernel TCP/IP stack as if they had been received on the "tap" device.
Users should not need to be concerned with this implementation detail.

Open vSwitch has a network device type called "tap".  This is intended only
for implementing "internal" ports in the OVS 

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

[Daniel Alvarez Sanchez]

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

[ovs-discuss] Problem on OpenVSwitch 2.9

[woz woz]

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.
Thanks in advance for your support,
Best regards

Woz
___
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]

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] OVN Database sizes - Auto compact feature

[Daniel Alvarez Sanchez]

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] OVN Database sizes - Auto compact feature

[Ben Pfaff]

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

[ovs-discuss] Apples to apples kernel vs userspace

[Blue Lang]

Hello everyone,

I have googled extensively but am not able to find a simple
apples-to-apples comparison of userspace vs kernel data path OVS
performance. Is there a handy comparison floating around for reference?

Thanks,

-- 
Blue Lang
VP, Engineering *| *Veracity

3423 Piedmont Rd NE

Suite 400

Atlanta, GA  30305
Cell:  (770) 265-1381 <+17702651381>
https://www.linkedin.com/in/bluelang/
b...@veracity.io
www.veracity.io
___
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

[Riccardo Ravaioli]

Hi Ian,

Thanks a lot for your patch. I applied your modifications and ran again the
setup described in the original post. While the CRC-related error message
has disappeared, openvswitch still crashes (with no gdb running!):

# tail ovs-vswitchd.log
2018-03-07T14:58:53.311Z|00215|dpdk|INFO|EAL: PCI device :05:10.1 on
NUMA socket 0
2018-03-07T14:58:53.311Z|00216|dpdk|INFO|EAL:   probe driver: 8086:1520
net_e1000_igb_vf
2018-03-07T14:58:53.518Z|00217|dpdk|INFO|PMD: eth_igbvf_dev_init(): VF
MAC address not assigned by Host PF
2018-03-07T14:58:53.518Z|00218|dpdk|INFO|PMD: eth_igbvf_dev_init():
Assign randomly generated MAC address fe:00:a5:78:49:2a
2018-03-07T14:58:53.518Z|00219|netdev_dpdk|INFO|Device ':05:10.1'
attached to DPDK
2018-03-07T14:58:53.518Z|00220|netdev_dpdk|ERR|Interface 2.switch1 MTU
(1500) setup error: Operation not supported
2018-03-07T14:58:53.518Z|00221|netdev_dpdk|ERR|Interface 2.switch1(rxq:1
txq:1) configure error: Operation not supported
2018-03-07T14:58:53.884Z|2|daemon_unix(monitor)|ERR|1 crashes: pid 4171
died, killed (Segmentation fault), core dumped, restarting

# lspci -s :05:10.1 -v
05:10.1 Ethernet controller: Intel Corporation I350 Ethernet Controller
Virtual Function (rev 01)
Flags: bus master, fast devsel, latency 0
[virtual] Memory at fbea (64-bit, prefetchable) [size=16K]
[virtual] Memory at fbe8 (64-bit, prefetchable) [size=16K]
Capabilities: [70] MSI-X: Enable- Count=3 Masked-
Capabilities: [a0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
Capabilities: [1a0] Transaction Processing Hints
Capabilities: [1d0] Access Control Services
Kernel driver in use: vfio-pci


This is indeed the second issue you mentioned in a previous post. Can we
get past this with a workaround?

Thanks again!

Riccardo



On 7 March 2018 at 14:41, Stokes, Ian  wrote:

> Hi Ricardo,
>
>
>
> After some more time to look at the issue you could do something like
> below to enable crc for the interface (Note I haven’t fully validated this).
>
>
>
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>
> index af9843a..28d7d1e 100644
>
> --- a/lib/netdev-dpdk.c
>
> +++ b/lib/netdev-dpdk.c
>
> @@ -700,6 +700,12 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev,
> int n_rxq, int n_txq)
>
>
>
>  conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
>
>NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
>
> +
>
> +/*
>
> + * Need to enable hw_strip_crc specifically for SRIOV devices.
>
> + */
>
> +conf.rxmode.hw_strip_crc = 1;
>
> +
>
>
>
> On my system this at least got past the configuration error when adding
> the SRIOV VF port and I was able to pass traffic through the port in a
> simple VF to phy port setup . As I’ve only completed minor validation on
> this maybe you could give it a shot and see if it works on your setup.
>
>
>
> With regards to the VSI queue error I mentioned in previous posts, with
> some more investigation I found this only occurred when running the setup
> of SRIOV VFs in DPDK with GDB, I was able to reproduce the same issue in
> the DPDK l2fwd sample app so it is not specific to OVS. Once you are not
> running OVS with GDB during the SRIOV setup it should be OK. I’ll need to
> look at this in a little bit more detail when I have time but for the
> moment it shouldn’t block you.
>
>
>
> Hope this helps,
>
>
>
> Regards
>
> Ian
>
>
>
>
>
>
>
> *From:* ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-bounces@
> openvswitch.org] *On Behalf Of *Stokes, Ian
> *Sent:* Thursday, February 1, 2018 11:52 AM
> *To:* riccardoravai...@gmail.com
>
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] segmentation fault when adding a VF in DPDK
> to a switch
>
>
>
> Hi Ricardo,
>
>
>
> Apologies for the delay. Unfortunately with the OVS 2.9 release I haven’t
> had much time to look at this further.
>
>
>
> At the very least I think work needs to be done for dpdk.c and
> netdev-dpdk.c to enable configuration of VFs specifically (to account for
> the HW_CRC and VSI queue configurations).
>
>
>
> There would also be a task to ensure the work required for enabling a VF
> on the i40e driver would also cover enabling a VF for the ixgbe driver. In
> DPDK it’s been the case in the past that driver implementations for
> different NIC devices can differ.
>
>
>
> This could be looked at in the OVS 2.10 development cycle at some point. I
> can post an update here when there is progress.
>
>
>
> Thanks
>
> Ian
>
>
>
> *From:* scaricapo...@gmail.com [mailto:scaricapo...@gmail.com
> ] *On Behalf Of *Riccardo Ravaioli
> *Sent:* Thursday, January 25, 2018 4:35 PM
> *To:* Stokes, Ian 
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] segmentation fault when adding a VF in DPDK
> to a switch
>
>
>
> Hi Ian,
>
> Thanks 

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

[Daniel Alvarez Sanchez]

Right, thanks Mark! Good point about the 4x, I missed that one.
I'm repeating the test for 1K ports. Not sure if I'll be able to reproduce
the 2.5GB part but it is still weird that while deleting ports (actually
deleting stuff from the DB) it doesn't get to compact the DB further
(last time it shrinked to 9MB) so maybe we have something odd here
going in the online compact. I'll post the results after this test.

On Wed, Mar 7, 2018 at 3:35 PM, Mark Michelson  wrote:

> On 03/07/2018 07:40 AM, Daniel Alvarez Sanchez wrote:
>
>> Hi folks,
>>
>> During the performance tests I've been doing lately I noticed
>> that the size of the Southbound database was around 2.5GB
>> in one of my setups. I couldn't dig further then but now I
>> decided to explore a bit more and these are the results in
>> my all-in-one OpenStack setup using OVN as a backend:
>>
>> * Created 800 ports on the same network (logical switch).
>> * Deleted those 800 ports.
>> * I logged the DB sizes for both NB and SB databases every second.
>>
>> See attached image for the results.
>>
>> At around x=2000, the creation task finished and deletion starts.
>> As you can see, there's automatic compact happening in the
>> NB database across the whole test. However, while I was deleting
>> ports, the SB database stop shrinking and keeps growing.
>>
>> After the test finished, the DB sizes remaining the same
>> thus SB database being around 34MB. It was not until I
>> manually compacted it when it finally shrinked:
>>
>>
>> [stack@ovn ovs]$ ls -alh ovnsb_db.db
>> -rw-r--r--. 1 stack stack 34M Mar  7 12:04 ovnsb_db.db
>>
>> [stack@ovn ovs]$ sudo ovs-appctl -t 
>> /usr/local/var/run/openvswitch/ovnsb_db.ctl
>> ovsdb-server/compact
>>
>> [stack@ovn ovs]$ ls -alh ovnsb_db.db
>> -rw-r--r--. 1 stack stack 207K Mar  7 13:32 ovnsb_db.db
>>
>> I'll try to investigate further in the code.
>> Thanks,
>>
>> Daniel
>>
>
> Daniel and I discussed this offline and I think the attached result does
> not necessarily indicate a bug yet.
>
> One of the requirements for the DB to compact automatically is that it
> needs to grow to at least 4x the size of the previous snapshot. In the
> graph, we can see that the first time the SB DB compacts (around x==1000),
> it shrinks down to ~5MB. We would expect the DB to compact again when it
> gets to ~20MB. This happens at around x==1900. The DB shrinks to ~9MB, so
> we would expect it to shrink again when it reaches ~36MB. When the test
> ends, the SB DB is ~34 MB, so it is not quite large enough to compact yet.
> If the test had gone a bit longer, then presumably we might have seen the
> DB shrink again.
>
> It will be interesting to see the test that leads to a 2.5GB southbound
> database.
>
> Mark!
>
___
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/07/2018 07:40 AM, Daniel Alvarez Sanchez wrote:

Hi folks,

During the performance tests I've been doing lately I noticed
that the size of the Southbound database was around 2.5GB
in one of my setups. I couldn't dig further then but now I
decided to explore a bit more and these are the results in
my all-in-one OpenStack setup using OVN as a backend:

* Created 800 ports on the same network (logical switch).
* Deleted those 800 ports.
* I logged the DB sizes for both NB and SB databases every second.

See attached image for the results.

At around x=2000, the creation task finished and deletion starts.
As you can see, there's automatic compact happening in the
NB database across the whole test. However, while I was deleting
ports, the SB database stop shrinking and keeps growing.

After the test finished, the DB sizes remaining the same
thus SB database being around 34MB. It was not until I
manually compacted it when it finally shrinked:


[stack@ovn ovs]$ ls -alh ovnsb_db.db
-rw-r--r--. 1 stack stack 34M Mar  7 12:04 ovnsb_db.db

[stack@ovn ovs]$ sudo ovs-appctl -t 
/usr/local/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/compact


[stack@ovn ovs]$ ls -alh ovnsb_db.db
-rw-r--r--. 1 stack stack 207K Mar  7 13:32 ovnsb_db.db

I'll try to investigate further in the code.
Thanks,

Daniel


Daniel and I discussed this offline and I think the attached result does 
not necessarily indicate a bug yet.


One of the requirements for the DB to compact automatically is that it 
needs to grow to at least 4x the size of the previous snapshot. In the 
graph, we can see that the first time the SB DB compacts (around 
x==1000), it shrinks down to ~5MB. We would expect the DB to compact 
again when it gets to ~20MB. This happens at around x==1900. The DB 
shrinks to ~9MB, so we would expect it to shrink again when it reaches 
~36MB. When the test ends, the SB DB is ~34 MB, so it is not quite large 
enough to compact yet. If the test had gone a bit longer, then 
presumably we might have seen the DB shrink again.


It will be interesting to see the test that leads to a 2.5GB southbound 
database.


Mark!
___
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]

BTW, I didn't spot any of these messages in the log:

https://github.com/openvswitch/ovs/blob/4cc9d1f03f83e9fac90a77ddaca0af662b2758b1/ovsdb/file.c#L615

I'll add a few traces to figure out why the auto compact is not triggering.

Also, I could see the trace when I ran it manually:
2018-03-07T13:32:21.672Z|00021|ovsdb_server|INFO|compacting OVN_Southbound
database by user request
2018-03-07T13:32:21.672Z|00022|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
compacting database online (1519124364.908 seconds old, 951 transactions)


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

> Hi folks,
>
> During the performance tests I've been doing lately I noticed
> that the size of the Southbound database was around 2.5GB
> in one of my setups. I couldn't dig further then but now I
> decided to explore a bit more and these are the results in
> my all-in-one OpenStack setup using OVN as a backend:
>
> * Created 800 ports on the same network (logical switch).
> * Deleted those 800 ports.
> * I logged the DB sizes for both NB and SB databases every second.
>
> See attached image for the results.
>
> At around x=2000, the creation task finished and deletion starts.
> As you can see, there's automatic compact happening in the
> NB database across the whole test. However, while I was deleting
> ports, the SB database stop shrinking and keeps growing.
>
> After the test finished, the DB sizes remaining the same
> thus SB database being around 34MB. It was not until I
> manually compacted it when it finally shrinked:
>
>
> [stack@ovn ovs]$ ls -alh ovnsb_db.db
> -rw-r--r--. 1 stack stack 34M Mar  7 12:04 ovnsb_db.db
>
> [stack@ovn ovs]$ sudo ovs-appctl -t 
> /usr/local/var/run/openvswitch/ovnsb_db.ctl
> ovsdb-server/compact
>
> [stack@ovn ovs]$ ls -alh ovnsb_db.db
> -rw-r--r--. 1 stack stack 207K Mar  7 13:32 ovnsb_db.db
>
> I'll try to investigate further in the code.
> Thanks,
>
> Daniel
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Daniel Alvarez Sanchez]

Hi folks,

During the performance tests I've been doing lately I noticed
that the size of the Southbound database was around 2.5GB
in one of my setups. I couldn't dig further then but now I
decided to explore a bit more and these are the results in
my all-in-one OpenStack setup using OVN as a backend:

* Created 800 ports on the same network (logical switch).
* Deleted those 800 ports.
* I logged the DB sizes for both NB and SB databases every second.

See attached image for the results.

At around x=2000, the creation task finished and deletion starts.
As you can see, there's automatic compact happening in the
NB database across the whole test. However, while I was deleting
ports, the SB database stop shrinking and keeps growing.

After the test finished, the DB sizes remaining the same
thus SB database being around 34MB. It was not until I
manually compacted it when it finally shrinked:


[stack@ovn ovs]$ ls -alh ovnsb_db.db
-rw-r--r--. 1 stack stack 34M Mar  7 12:04 ovnsb_db.db

[stack@ovn ovs]$ sudo ovs-appctl -t
/usr/local/var/run/openvswitch/ovnsb_db.ctl ovsdb-server/compact

[stack@ovn ovs]$ ls -alh ovnsb_db.db
-rw-r--r--. 1 stack stack 207K Mar  7 13:32 ovnsb_db.db

I'll try to investigate further in the code.
Thanks,

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

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

[Miguel Angel Ajo Pelayo]

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 "vlan50"
tag: 50
Interface "vlan50"
type: internal
Port "vlan20"
tag: 20
Interface "vlan20"
type: internal
ovs_version: "2.8.1"
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss