ofpbuf: Add private pointer for dpdk

netdev-dpdk uses this pointer to store dpdk mbuf. This patch fixes
compilation error in dpdk.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
ofpbuf: Introduce access api for base, data and size.

These functions will be used by later patches.  Following patch
does not change functionality.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
ofpbuf: Add ofpbuf_init_dpdk()

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
ofpbuf: Add DPDK mbuf to ofpbuf.

Define data, base and size access APIs for DPDK.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
netdev-dpdk: Remove alloc from packet recv.

On DPDK packet recv, ovs is given pointer to mbuf which has
information about a packet, for example pointer to data and size.
By moving mbuf to ofpbuf we can let dpdk allocate ofpbuf and
pass that to ovs for processing the packet.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
debian: Allow kmod or module-init-tools for backward compatibility.

Commit d473844693 (debian: Depend on 'kmod' instead of module-init-tools.)
switched from depending on module-init-tools to depending on kmod, which
is the new name of the appropriate package in Debian.  Unfortunately,
while kmod is the right name for the latest Debian distribution, it doesn't
have that name in old distributions and thus breaks the build on those.
This commit should work OK in either case, since it allows both names.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Gurucharan Shetty <gshetty@nicira.com>
ovsdb-client: Support all vlog options.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
ovsdb-server: Send update for _version for changes due to weak ref removal.

When a row was deleted, and that caused the transaction manager to remove
a remaining weak reference to the row, and no other change had been made
to the row in that transaction, and a client was monitoring modifications
of the _version column in the row, then the monitor update for the column
did not include the old contents of the _version column, even though it
should have.  This commit fixes the problem.

Probably most clients only look at the new value of the column, if they
monitor _version at all, and this bug is really old, so it's probably
not a serious bug.

Found by inspection.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Revert "jsonrpc-server: Add test for disconnecting connections with too long queues."

This reverts commit 631583739f9aec55d4cbe25fb856143ccde48ab6.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  An upcoming patch implements this new way.  This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Revert "jsonrpc-server: Disconnect connections that queue too much data."

This reverts commit 60533a405b2eb77214b767767fe143c8645f82d5.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  An upcoming patch implements this new way.  This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Revert "ovsdb-data: New functions for predicting serialized length of data."

This reverts commit 0ea7bec76d804a2c4efccd3dbdaa3e30cf536a5c.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  An upcoming patch implements this new way.  This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
Revert "json: New function json_serialized_length()."

This reverts commit 1600fa6853872e16130366351a2c14f6fa8b547c.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  An upcoming patch implements this new way.  This commit
reverts part of the previous solution that disconnects backlogged
connections, since it is no longer useful.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
jsonrpc-server: Track monitor updates separately from sending them.

This will make combining monitor updates easier in the next commit.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
jsonrpc-server: Combine notifications when connection becomes backlogged.

Connections that queue up too much data, because they are monitoring a
table that is changing quickly and failing to keep up with the updates,
cause problems with buffer management.  Since commit 60533a405b2e
(jsonrpc-server: Disconnect connections that queue too much data.),
ovsdb-server has dealt with them by disconnecting the connection and
letting them start up again with a fresh copy of the database.  However,
this is not ideal because of situations where disconnection happens
repeatedly.  For example:

     - A manager toggles a column back and forth between two or more values
       quickly (in which case the data transmitted over the monitoring
       connections always increases quickly, without bound).

     - A manager repeatedly extends the contents of some column in some row
       (in which case the data transmitted over the monitoring connection
       grows with O(n**2) in the length of the string).

A better way to deal with this problem is to combine updates when they are
sent to the monitoring connection, if that connection is not keeping up.
In both the above cases, this reduces the data that must be sent to a
manageable amount.  This commit implements this new way.

Bug #1211786.
Bug #1221378.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
unit-test: Improve ovstest user interface

Improve help output. Running without argument now exit with an error
message and an error code. Simplify OVSTEST_REGISTER() since not all
test programs uses sub_commands.

Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
unit-test: Link 29 test programs into ovstest

Improve link speed by linking 29 test programs into ovstest.

On my machine, running the following command against a fully
built tree:

  $ touch lib/random.c; time make

Improve the overall build time from 7 seconds to 3.5 seconds.

Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
tests: add ovstest to .gitignore

Signed-off-by: Lorand Jakab <lojakab@cisco.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofpbuf: Rename trivial _get_ functions without the "get".

Code reads better without the "get", for example "ofpbuf_l3()"
v.s. "ofpbuf_get_l3()".  L4 payoad access functions still use the
"get" (e.g., "ofpbuf_get_tcp_payload()").

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
ofpbuf: Abstract 'l2' pointer and document usage conventions.

Rename 'l2' to 'frame' and add new ofpbuf_set_frame() and ofpbuf_l2().
ofpbuf_set_frame() alse resets all the layer offsets.  ofpbuf_l2()
returns NULL if the packet has no Ethernet header, as indicated either
by unset l3 offset or NULL frame pointer.  Callers of ofpbuf_l2() are
supposed to check the return value, unless they can otherwise be sure
that the packet has a valid Ethernet header.

The recent commit 437d0d22 made some assumptions that were not valid
regarding the use of the 'l2' pointer in rconn module and by
compose_rarp().  This is now fixed as follows: rconn now relies on the
fact that once OpenFlow messages are given to rconn for transport, the
frame pointer is no longer needed to refer to the OpenFlow header; and
compose_rarp() now sets the frame pointer and offsets as expected.

In addition to storing network frames, ofpbufs are also used for
handling OpenFlow messages and action lists.  lib/ofpbuf.h now has a
comment documenting the current usage conventions and invariants.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
bridge: don't bring up internal ports by default.

It should be an administrator task to bring up devices as they
are configured properly.

Currently, Fedora is deleting the bridges when the interface is
brought down. Therefore, there is no bridge on the next boot and
the initscripts can apply the networking configuration properly
for a new bridge.

However, if the system didn't execute ifdown for some reason, the
bridge is left in the ovsdb and since internal ports are brought
up by default, there is no way for initscripts to known if the
adminitrator has already configured it or not.

This patch reverts commit bef071a5fdf8e2dd87677b04b3cf7a8f5094edcb
(bridge: Always "up" internal devices.).

Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>