Now that struct cls_match has 'add_version' the 'version' in cls_match
was largely redundant. Remove 'version' from struct cls_rule, and add
it to function prototypes that need it. This makes versioning more
explicit (or less indirect) in the API.
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It is cleaner to not use ofp_bundle_entry for non-bundle flow mods.
To address this, the new struct ofproto_flow_mod combines an
ofputil_flow_mod and the necessary execution context for executing the
start, revert, and finish phases of the flow mod, which all were
previously members of struct ofp_bundle_entry.
This also simplifies many of the function prototypes introduced with
the OF 1.4 bundles code. However, in case of learn action execution
this approach requires a new copy of the ofputil_flow_mod. This could
be avoided by making struct ofproto_flow_mod more complex, but it
seems not worth the complication.
As part of carving out the execution context from ofp_bundle_entry to
ofproto_flow_mod, the 'version' member is now also in
ofproto_flow_mod, as it makes sense for flow mods, but not for port
mods. Now that the functions operate on the version also get the full
execution context, they use 'version' instead of
'ofproto->tables_version'. This allows ofproto->tables_version to be
changed only when a new version is committed.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Datapath support for some flow key fields is used inside ofproto-dpif as
well as odp-util. Share these fields using the same structure.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
This BSOD occurred in the context of a packet (NBL) with multiple
NET_BUFFER(s) (NBs). The reason for the BSOD is due to the marking
of NBLs created by OVS as being external and wrongly completing them.
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/82
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
"ovs-appctl dpif/show" no longer takes any argument after commit dc54ef36
(ofproto: Track subfacet stats in the backer).
Signed-off-by: Huanle Han <hanxueluo@gmail.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
To enable SSL clients to reconnect with the ovs-testcontoller without being
rejected, one must either set the SSL Session ID flag or disable the
SSL caching. This patch disables the SSL caching/reuse.
In the absence of this fix, the error message from ovs-testcontroller is as
below:
SSL protocol error: SSL_accept (error:140D9115:SSL
routines:SSL_GET_PREV_SESSION:session id context uninitialized)
See <https://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html>.
Validation: Tested with ovs-testcontroller, by performing SSL reconnection
with OpenSSL based SSL client.
Signed-off-by: Guru Chaitanya Perakam <gperakam@brocade.com>
Reported-by: Guru Chaitanya Perakam <gperakam@brocade.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
OpenFlow 1.4 introduces the ability to turn on flow table eviction with an
OFPT_TABLE_MOD message specifying OFPTC_EVICTION. It also adds related
machinery to other messages that mention OFPTC_* fields. This commit adds
support for the new feature, implementing it as a second, parallel way to
enable flow table eviction. It takes more work than it seems like it
should because there is so much weirdness with the treatment of OFPTC_*
flags over the evolution of OpenFlow; please refer to the explanation in
DESIGN.md for more information.
This commit also adds related support to ovs-ofctl, plus tests.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Co-authored-by: Saloni Jain <saloni.jain@tcs.com>
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
The "importance" field is considered before flow timeout because I figure
that if you set the importance, you think it's important.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Co-authored-by: Saloni Jain <saloni.jain@tcs.com>
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
OpenFlow provides no means to change the importance of a flow after it is
added, so make it immutable so that it is reasonable to read it without
locking.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Until now, the OVN_Northbound schema has been designed to sidestep a
weakness in the OVSDB protocol when a column has a great deal of data in
it. In the current OVSDB protocol, whenever a column changes, the entire
new value of the column is sent to all of the clients that are monitoring
that column. That means that adding or removing a small amount of data,
say 1 element in a set, requires sending all of the data, which is
expensive if the column has a lot of data.
One example of a column with potential to have a lot of data is the set of
ports within a logical switch, if a logical switch has a large number of
ports. Thus, the existing OVN_Northbound schema has each Logical_Port
point to its containing Logical_Switch instead of the other way around.
This sidesteps the problem because it does not use any large columns.
The tradeoff that this forces, however, is that the schema cannot take
advantage of OVSDB's garbage collection feature, where it automatically
deletes rows that are unreferenced. That's a problem for Neutron because
of Neutron-internal races between deletion of a Logical_Switch and
creation of new Logical_Ports on the switch being deleted. When such a
race happens, OVSDB refuses to delete the Logical_Switch because of
references to it from the newly created Logical_Port (although Neutron
does delete the pre-existing logical ports).
To solve the problem, this commit changes the OVN_Northbound schema to
use a set of ports within Logical_Switch. That will lead to large columns
for large logical switches; I plan to address that (though I don't have
code written) by enhancing the OVSDB protocol. With this commit applied,
the database will automatically cascade deleting a logical switch row to
delete all of its ports, ACLs, and its router port (if any).
This commit makes some pretty pervasive changes to ovn-northd, but they
are mostly beneficial to the code readability because now it becomes
possible to trivially iterate through the ports that belong to a switch,
which was difficult before the schema change.
This commit will break the Neutron integration until that is changed to
handle the new database schema.
CC: Aaron Rosen <arosen@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Russell Bryant <rbryant@redhat.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
ofproto_enable_eviction() and ofproto_disable_eviction() require
ofproto_mutex (and they were even annotated that way, though not on their
prototypes but only at definition), but it wasn't being held. This fixes
the problem.
Found by inspection.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
When closing opened instances, make sure the user dump state is cleared.
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/90
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add check in case of NdisAllocateRWLock fails to allocate the resources.
Check datapath->lock before trying to free it.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Reported-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/92
Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add support for MLDv1 and MLDv2. The behavior is not that different from
IGMP. Packets to all-hosts address and queries are always flooded,
reports go to routers, routers are added when a query is observed, and
all MLD packets go through slow path.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Cc: Flavio Leitner <fbl@redhat.com>
Cc: Ben Pfaff <blp@nicira.com>
[blp@nicira.com moved an assignment out of an 'if' statement]
Signed-off-by: Ben Pfaff <blp@nicira.com>
Use IPv6 internally for storing multicast addresses. IPv4 addresses are
translated to their IPv4-mapped equivalent.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Cc: Flavio Leitner <fbl@redhat.com>
Cc: Ben Pfaff <blp@nicira.com>
[blp@nicira.com added a "sparse" implementation of IN6_IS_ADDR_V4MAPPED.]
Signed-off-by: Ben Pfaff <blp@nicira.com>
OvsPrepareFlow() returns an error only when the new flow allocation
fails. In this case HandleFlowPut() should return error without trying
to free the flow, thus avoiding the BSOD.
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/91
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The addition of Geneve options to packet metadata significantly
expanded its size. It was reported that this can decrease performance
for DPDK ports by up to 25% since we need to initialize the whole
structure on each packet receive.
It is not really necessary to zero out the entire structure because
miniflow_extract() only copies the tunnel metadata when particular
fields indicate that it is valid. Therefore, as long as we zero out
these fields when the metadata is initialized and ensure that the
rest of the structure is correctly set in the presence of a tunnel,
we can avoid touching the tunnel fields on packet reception.
Reported-by: Ciara Loftus <ciara.loftus@intel.com>
Tested-by: Ciara Loftus <ciara.loftus@intel.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Looking at the code, the flag 'vport->isPresentOnHv' is actually
indicating if the vport is present on the Hyper-V switch or not, but the
logic seems to be inverse. 'isPresentOnHv == TRUE' indicates that the
vport is not present on the Hyper-V switch. Eg. VXLAN port, would have
isPresentOnHv == TRUE.
In this patch, we rename the variable to reflect its meaning.
vport->isAbsentOnHv is TRUE iff:
- vport is bridge internal port
- vport is tunnel port
- vport was added from Hyper-V and also from OVS, but got deleted from
Hyper-V
Signed-off-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
In this patch, there a couple of fixes and some code refactoring:
1. During deletion of "internal" and "external" in
OvsRemoveAndDeleteVport(), we need to check if 'hvDelete' is TRUE before
updating the data structures. Added code comments explaining the
same.
2. Added a OvsRemoveTunnelPort() that gets called from
OvsRemoveAndDeletePort() for the special processing for tunnel ports.
3. Folded in OvsCleanupVportCommon() back into OvsRemoveAndDeletePort(),
since we only need a part of the functionality of
OvsCleanupVportCommon() to be called from
OvsTunnelVportPendingUninit(), and not the entire function.
4. Renamed OvsTunnelVportPendingUninit() to
OvsTunnelVportPendingRemove() since it is basically a "pending" version
of OvsVportTunnelRemove().
Validation:
- Add external port from Hyper-V, add external port from OVS, remove
external port from OVS, remove external port from Hyper-V. No ASSERT
hit.
- Add external port from Hyper-V, add external port from OVS, remove
external port from Hyper-V, remove external port from OVS. No ASSERT
hit.
- Vxlan tunnel port creation/deletion
- Stt tunnel port creation/deletion
- Ping on Vxlan/Stt tunnels
- Ovs Extension load/unload. There's an unrelated issue I found that is
reported in: https://github.com/openvswitch/ovs-issues/issues/86
Signed-off-by: Nithin Raju <nithin@vmware.com>V
Reported-at: https://github.com/openvswitch/ovs-issues/issues/79
Reported-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Reported-by: Nithin Raju <nithin@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Currently OVS_UNUSED is defined in compiler.h since syslog.h is a
standalone wrapper remove it from the parameters.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Tunnel ports are not initialized with the corresponding default port.
The newly allocated vport is not yet initialized and the ovsType
member does not reflect the correct tunnel port type, thus the
transport port destination won't be correctly initialized.
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Reported-at: https://github.com/openvswitch/ovs-issues/issues/88
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
All pool allocations should have unique tags.
OVS_STT_POOL_TAG matches the OVS_MEMORY_TAG.
Changed the OVS_STT_POOL_TAG to make it unique.
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Acked-by: Eitan Eliahu <eliahue@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The ability to move IP address and routes between two interfaces
is useful when we want to make a physical interface (say eth0)
as a port of OVS bridge (say breth0) with all its IP address and route
information transferred to OVS bridge. An upcoming commit
uses the new ability.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
An upcoming commit becomes the second user of the
new functions.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit adds a rpmbuild spec file for building ovs datapath
in dkms similar to the one for debian.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
This patch allows to query logging format at the runtime for each destination
with "vlog/list-pattern" command.
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch helps to address two issues that are present on Ubuntu
15.04 (and most likely other Linux distributions) where rsyslog daemon
is configured to relay log messages from OVS to a remote log collector
and syslog format being used is something other than the one defined in
RFC 3164. These two issues are:
1. libc syslog() function always adds RFC 3164 prefix to syslog
messages before sending them over /dev/log Unix domain socket.
This does not allow us to use libc syslog() function to log in
RFC 5424 format; and
2. rsyslogd daemon that comes with Ubuntu 15.04 is too old and
uses hardcoded syslog message parser when it received messages
over /dev/log UNIX domain socket.
Solution to those two issues would be to use the newly introduced
--syslog-method=udp:127.0.0.1:514 command line argument when starting
OVS.
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Currently the userspace datapath only supports Geneve in a
basic mode - without options - since the rest of userspace
previously didn't support options either. This enables the
userspace datapath to send and receive options as well.
The receive path for extracting the tunnel options isn't entirely
optimal because it does a lookup on the options on a per-packet
basis, rather than per-flow like the kernel does. This is not
as straightforward to do in the userspace datapath since there
is no translation step between packet formats used in packet vs.
flow lookup. This can be optimized in the future and in the
meantime option support is still useful for testing and simulation.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Groups were not destroyed until after lots of other important bridge
data had been destroyed, including the connection manager. There was an
indirect dependency on the connection manager for bridge destruction
because destroying a group also destroys all of the flows that reference
the group, which in turn causes the ofmonitor to be invoked to report that
the flows had been destroyed. This commit fixes the problem by destroying
groups earlier.
The problem can be observed by reverting the code changes in this commit
then running "make check-valgrind" with the test that this commit
introduces.
Reported-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
It doesn't make sense to mix "conjunction" actions with most other kinds
of actions. That's because flows with "conjunction" actions aren't ever
actually executed, so any actions mixed up with them would never do
anything useful. "note" actions are a little different because they never
do anything useful anyway: they are just there to allow a controller to
annotate flows. It makes as much sense to annotate a flow with
"conjunction" actions as it does to annotate any other flow, so this
commit makes this possible.
Requested-by: Soner Sevinc <sevincs@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Andy Zhou <azhou@nicira.com>
When doing native tunneling, we look at packets destined to the
local port to see if they match tunnel protocols that we should
intercept. The criteria are IP protocol, destination UDP port, etc.
However, we also look at the source IP address of the packets. This
should be a function of the port-based tunnel layer and not the
tunnel receive code itself. For comparison, the kernel tunnel code
has no idea about the IP addresses of its link partners. If port
based tunnel is desired, it can be handled using the normal port
tunnel layer, regardless of whether the packets originally came
from userspace or the kernel.
For port based tunneling, this bug has no effect - the check is
simply redundant. However, it breaks flow-based native tunnels
because the remote IP address is not known at port creation time.
CC: Pravin Shelar <pshelar@nicira.com>
Reported-by: David Griswold <David.Griswold@overturenetworks.com>
Tested-by: David Griswold <David.Griswold@overturenetworks.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
When using multiple PMDs and numerous ports, a performance gain
may be achieved in some use cases by pinning a PMD/port to a
particular (set of) core(s).
This patch provides a summary of the switch's port/core affinities
each time that the status of the switch's ports is modified.
Based on this information, a user may determine what affinity
modifications are required to optimise performance for their
particular use case.
Signed-off-by: Mark Kavanagh <mark.b.kavanagh@intel.com>
Signed-off-by: Wojciech Andralojc <wojciechx.andralojc@intel.com>
Acked-by: Flavio Leitner <fbl@redhat.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
When tx queue is shared among CPUS,the pkts always be flush
in 'netdev_dpdk_eth_send'. So it is unnecessarily for flushing
in netdev_dpdk_rxq_recv Otherwise tx will be accessed without
locking.
Signed-off-by: Wei li <liw@dtdream.com>
Acked-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
The addition of Geneve metadata requires a large amount of additional
space to handle the maximum set of options. In most cases, this is
not a big deal since it is only temporary storage on the stack or
can be automatically stripped out for miniflows. However, userspace
tunnels need to deal with this on a per-packet basis, so we should
avoid introducing additional overhead if possible. Two small changes
are aimed at this:
* Move struct flow_tnl to the end of the packet metadata. Since
the Geneve metadata is already at the end of flow_tnl and pkt_metadata
is at the end of struct dp_packet, this avoids putting a large
amount metadata (which might be empty) in hot cache lines.
* Only push the new metadata into a miniflow if any options are present
during miniflow_extract(). This does not necessarily provide the
most fine-grained flow generation but it is a quick check and
the userspace implementation of Geneve does not currently support
options anyways.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The current support for Geneve in OVS is exactly equivalent to VXLAN:
it is possible to set and match on the VNI but not on any options
contained in the header. This patch enables the use of options.
The goal for Geneve support is not to add support for any particular option
but to allow end users or controllers to specify what they would like to
match. That is, the full range of Geneve's capabilities should be exposed
without modifying the code (the one exception being options that require
per-packet computation in the fast path).
The main issue with supporting Geneve options is how to integrate the
fields into the existing OpenFlow pipeline. All existing operations
are referred to by their NXM/OXM field name - matches, action generation,
arithmetic operations (i.e. tranfer to a register). However, the Geneve
option space is exactly the same as the OXM space, so a direct mapping
is not feasible. Instead, we create a pool of 64 NXMs that are then
dynamically mapped on Geneve option TLVs using OpenFlow. Once mapped,
these fields become first-class citizens in the OpenFlow pipeline.
An example of how to use Geneve options:
ovs-ofctl add-geneve-map br0 {class=0xffff,type=0,len=4}->tun_metadata0
ovs-ofctl add-flow br0 in_port=LOCAL,actions=set_field:0xffffffff->tun_metadata0,1
This will add a 4 bytes option (filled will all 1's) to all packets
coming from the LOCAL port and then send then out to port 1.
A limitation of this patch is that although the option table is specified
for a particular switch over OpenFlow, it is currently global to all
switches. This will be addressed in a future patch.
Based on work originally done by Madhu Challa. Ben Pfaff also significantly
improved the comments.
Signed-off-by: Madhu Challa <challa@noironetworks.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Sometimes we need to look at flow fields to understand how to parse
an attribute. However, masks don't have this information - just the
mask on the field. We already use the translated flow structure for
this purpose but this isn't always enough since sometimes we actually
need the raw netlink information. Fortunately, that is also readily
available so this passes it down from the appropriate callers.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Tunnel metadata can be substantially larger than our existing fields
(up to 124 bytes in a single Geneve option) so this extends the size
of the data that we can handle with metaflow fields. This also
breaks a few tests that assume that their max size is also the
maximum that can be handled in a field.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
In order to work with Geneve options, we need to maintain a mapping
table between an option (defined by <class, type, length>) and
an NXM field that can be operated on for the purposes of matches,
actions, etc. This mapping must be explicitly specified by the
user.
Conceptually, this table could be communicated using either OpenFlow
or OVSDB. Using OVSDB requires less code and definition of extensions
than OpenFlow but introduces the possibility that mapping table
updates and flow modifications are desynchronized from each other.
This is dangerous because the mapping table signifcantly impacts the
way that flows using Geneve options are installed and processed by
OVS. Therefore, the mapping table is maintained using OpenFlow commands
instead, which opens the possibility of using synchronization between
table changes and flow modifications through barriers, bundles, etc.
There are two primary groups of OpenFlow messages that are introduced
as Nicira extensions: modification commands (add, delete, clear mappings)
and table status request/reply to dump the current table along with switch
information.
Note that mappings should not be changed while they are in active use by
a flow. The result of doing so is undefined.
This only adds the OpenFlow infrastructure but doesn't actually
do anything with the information yet after the messages have been
decoded.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
When reading in hex strings that form NXM fields, we don't need to
enforce size constraints if the fields are variable length.
Instead, we can set the header size based on the string length.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It is technically correct to send the entire maximum length of
a field when it is variable length. However, it is awkward to
do so and not what one would naively expect. Since receivers will
internally zero-extend fields, we can do the opposite and trim
off leading zeros. This results in encodings that are generally
sensible without specific knowledge of what is being transmitted.
(Of course, other implementations, such as controllers, may know
exactly the expected length of the field and are free to encode
it that way even if it has leading zeros.)
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Currently when an NXM field is encoded, the caller must specify
the length of the data being provided. However, this data is
always placed into a field of standard length. In order to
support variable length options, the length field must also
alter the size in the header. The previous implementation
already required callers to pass in the exact (fixed) size of
the field or it would not work properly, so there is no danger
that this will change the behavior for non-variable length
fields.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
