ofproto/xlate: Add xlate_lookup_ofproto().

"xlate_receive" did not tell much about what it is used for.  We have
two users of it that only want the ofproto and the OF port number, use the
new xlate_lookup_ofproto() for those.

Fix the comments of xlate_receive() as we no longer change the flow.

Also, the helper ofproto_dpif_contains_flow() seemed ill-named, so this
path removes it and uses xlate_lookup_ofproto() directly.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-upcall: Remove struct upcall netflow member.

The netflow member was not used for anything, so it can be removed.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-xlate: Do not take references in xlate_receive().

xlate configuration (via xcfg) is already holding the references, so
the callers of xlate_receive() can safely use the returned pointers
upto the point when they quiesce.  If the objects are needed for
longer term, the callers can take additional references themselves.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-xlate: Rename xlate_receive() as xlate_lookup().

Seems better as we no longer modify the flow.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
build: Add travis continuous integration support

This enables the use of travis-ci via github. Linking any ovs
github repo to travis-ci [0] will automatically lead to a build
and testsuite run being triggered for each new commit or pull
requests against the repo.

The introduction of any warnings will cause the build to fail as
both gcc and clang are invoked with -Werror.

The build matrix currently includes:
  * --disable-ssl
  * --with-linux=linux-3.14.7
  * --with-dpdk=1.7.0

Each of these builds is performed with gcc+sparse and clang. The
testsuite is only run for the --with-linux build to keep the total
build time on an acceptable level.

Build failures are reported to the author and commiter by email,
through the travis-ci web UI, and in the github pull request.

A full build report example can be found here [1]

[0] http://travis-ci.org/
[1] https://travis-ci.org/tgraf/ovs/builds/33485228

Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-xlate: Only learn MAC addresses upon handling packets.

MAC learning, like flow entry learning via the "learn" action, should only
happen if a packet was actually received.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
ofproto-dpif-xlate: Skip pushing stats if there are no packets to push.

xlate_push_stats() mostly does nothing if 'stats->n_packets' is 0.  This
commit allows it to skip more complicated internal logic in that case.

The one case I see in which xlate_push_stats() does do something if
'stats->n_packets' is 0 is in the case of a cached fin_timeout translation.
That translation changes the idle and hard timeouts of a flow if tcp_flags
has FIN or RST set, even if n_packets is 0.  But I don't think that can
happen anyway; how would FIN or RST be set without receiving a packet?

More broadly, the xlate_push_stats handles two functions - pushing stats
and implementing side-effects from actions. If there are no packets, the
stats shouldn't need updating. If there were no packets, then no packets
could have hit actions for things such as mac learning/openflow learning,
so xlate_push_stats() should be a no-op.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
ofproto-dpif-xlate: Drop 'may_learn' parameter from xlate_push_stats().

Both existing callers calculated 'may_learn' as 'stats->n_packets > 0', so
it was redundant.  Because xlate_push_stats() is now entirely a no-op if
'stats->n_packets' is 0, we can now delete the tests entirely from the
cases that previously only ran if 'may_learn'.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
ofproto-dpif-upcall: Attribute statistics to OpenFlow flows more precisely.

OpenFlow packet and byte counters have always been something of an
approximation in Open vSwitch.  First, they are updated only periodically.
Second, they can be misattributed because statistics collection does a
retranslation and gives the statistics to whichever OpenFlow flow or flows
they happen to hit, which could be different from the original set of
flows because the OpenFlow flow table may have changed.

This commit is intended to somewhat improve on the second point, by always
attributing statistics to the set of flows that were cached at the datapath
flow's initial translation by the revalidator.  This reduces the race in
which the flow table could have changed to the interval between the initial
installation and the first translation by the revalidator.  We plan to
start having the thread that does the initial installation also create the
ukey, which would eliminate that interval entirely.  At that point, packets
could get lost from OpenFlow statistics because of the periodic collection
of datapath statistics, but they should no longer be misattributed.

Signed-off-by: Ben Pfaff <blp@nicira.com>