The 'xid' in an ofp_header is not interpreted by the receiver but only by
the sender, so it need not be in any particular byte order. OVS used to
try to take advantage of this to avoid host/network byte order conversions
for this field. Older code in OVS, therefore, treats xid as being in host
byte order. However, as time went on, I forgot that I had introduced this
trick, and so newer code treats xid as being in network byte order.
This commit fixes up the situation by consistently treating xid as being
in network byte order. I think that this will be less surprising and
easier to remember in the future.
This doesn't fix any actual bugs except that some log messages would have
printed xids in the wrong byte order.
I don't know of any reason why the transaction id should be random. Using
consecutive ids means that there is no chance that two messages sent around
the same time will have the same transaction ID, which is probabilitically
possible with random IDs.
Our controller group at Nicira has requested a way to annotate flows with
extra information beyond the flow cookie. The new NXAST_NOTE action
provides such a way.
This new action is somewhat controversial. Some have suggested that it
should be added another way (either as part of the Nicira Extended Match
or as a new component of the flow_mod and related messages). Others think
that it has no place in the OpenFlow protocol at all and that an equivalent
should be implemented using the already available features of OVSDB. So
it is possible that this extension will be deleted and the feature will
be reimplemented some other way (or not at all).
CC: Teemu Koponen <koponen@nicira.com>
CC: Jeremy Stribling <strib@nicira.com>
The upcoming support for actions on registers will require the flow to
validate actions, so this commit adds the parameter in advance. It is
not yet used.
An upcoming commit will require the flow to be passed in as part of
OpenFlow action validation, but handle_packet_out() has until now been
structured to make this difficult. This commit refactors it to better
suit this purpose.
This breaks this OpenFlow handler into two parts, one responsible
for parsing and constructing OpenFlow messages and one that works
with the flow table. The latter will be reused in a later commit
that implements the Nicira Extended Match flexible flow match
extension.
There's no need to have a mask in this action, because both parts of the
TCI are part of the flow structure.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When userspace and the kernel were using the same structure for flows,
flow_t was a useful way to indicate that a structure was really a userspace
flow instead of a kernel one, but now it's better to just write "struct
flow" for consistency, since OVS doesn't use typedefs for structs
elsewhere.
Acked-by: Jesse Gross <jesse@nicira.com>
GNU libc treats malloc(0) as malloc(1). Subrules always have an n_actions
of 0, so this code was wasting time and memory for subrules. This commit
stops doing that.
Also audits and fixes some very pedantic potential problems with null
pointers; e.g. the C standard says that NULL may not be compared with the
< operator, even if both arguments are null, and it also says that a null
pointer may not be passed to memcpy() or memcmp(), even if the length is
zero.
The OpenFlow OFPAT_ENQUEUE action sets a queue id and outputs the packet
in one shot. There are times in which the queue should be set, but the
output port is not yet known. This commit adds the NXAST_SET_QUEUE and
NXAST_POP_QUEUE Nicira extension actions to modify the queue
configuration without requiring a port argument.
CC: Jeremy Stribling <strib@nicira.com>
CC: Keith Amidon <keith@nicira.com>
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
Open vSwitch has always "normalized" flows, that is, zeroed out fields that
are wildcarded or that otherwise cannot affect whether a packet actually
matches the flow. But until now it has done so silently, which prevents
the authors of controllers from learning what is happening and makes it
less likely that they will update code on their end. This commit makes
OVS log when normalization changes a flow.
Suggested by partner.
The OpenFlow reference implementation was sensibly normalizing these
fields but OVS did not. This change should make OVS resemble the OpenFlow
reference implementation at least in this respect.
For more information:
https://mailman.stanford.edu/pipermail/openflow-spec/2010-June/001040.html
Reported-by: Takayuki HAMA <t-hama@cb.jp.nec.com>
ovs-vswitchd doesn't declare its QoS capabilities in the database yet,
so the controller has to know what they are. We can add that later.
The linux-htb QoS class has been tested to the extent that I can see that
it sets up the queues I expect when I run "tc qdisc show" and "tc class
show". I haven't tested that the effects on flows are what we expect them
to be. I am sure that there will be problems in that area that we will
have to fix.
The main purpose of the vconn code is to ship OpenFlow messages across
network connections. Over time a large number of utility functions related
to OpenFlow messages have also crept into vconn.c, but that's really
logically separate. This commit breaks those functions out into a new
file.
