This patch adds a new action 'check_pkt_larger' which checks if the
packet is larger than the given size and stores the result in the
destination register.
Usage: check_pkt_larger(len)->REGISTER
Eg. match=...,actions=check_pkt_larger(1442)->NXM_NX_REG0[0],next;
This patch makes use of the new datapath action - 'check_pkt_len'
which was recently added in the commit [1].
At the start of ovs-vswitchd, datapath is probed for this action.
If the datapath action is present, then 'check_pkt_larger'
makes use of this datapath action.
Datapath action 'check_pkt_len' takes these nlattrs
* OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for
* OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER (optional) - Nested actions
to apply if the packet length is greater than the specified 'pkt_len'
* OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL (optional) - Nested
actions to apply if the packet length is lesser or equal to the
specified 'pkt_len'.
Let's say we have these flows added to an OVS bridge br-int
table=0, priority=100 in_port=1,ip,actions=check_pkt_larger:100->NXM_NX_REG0[0],resubmit(,1)
table=1, priority=200,in_port=1,ip,reg0=0x1/0x1 actions=output:3
table=1, priority=100,in_port=1,ip,actions=output:4
Then the action 'check_pkt_larger' will be translated as
- check_pkt_len(size=100,gt(3),le(4))
datapath will check the packet length and if the packet length is greater than 100,
it will output to port 3, else it will output to port 4.
In case, datapath doesn't support 'check_pkt_len' action, the OVS action
'check_pkt_larger' sets SLOW_ACTION so that datapath flow is not added.
This OVS action is intended to be used by OVN to check the packet length
and generate an ICMP packet with type 3, code 4 and next hop mtu
in the logical router pipeline if the MTU of the physical interface
is lesser than the packet length. More information can be found here [2]
[1] - 4d5ec89fc8
[2] - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Numan Siddique <nusiddiq@redhat.com>
CC: Ben Pfaff <blp@ovn.org>
CC: Gregory Rose <gvrose8192@gmail.com>
Acked-by: Mark Michelson <mmichels@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The assertions make it easier to find all the places that need to be
updated when adding protocol support.
Acked-by: Numan Siddique <nusiddiq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The assertions make it easier to find all the places that need to be
updated when adding protocol support.
Acked-by: Numan Siddique <nusiddiq@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
To improve performance and avoid wasting resources for HW offloaded
flows, do not rewrite fields that are matched with the same value.
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Eli Britstein <elibr@mellanox.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
If NULL value was provided for odp_flow_from_string errorp argument
segmentation fault error occurred.
This patch fixes it by ignoring error formatting if error pointer
is not provided.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12972
Signed-off-by: Toms Atteka <cpp.code.lv@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
As a side effect, this also reduces a lot of log messages' severities from
ERR to WARN. They just didn't seem like messages that in general reported
anything that would prevent functioning.
Signed-off-by: Ben Pfaff <blp@ovn.org>
If enough large input is passed to odp_actions_from_string it can
cause netlink attribute to overflow.
Check for buffer size was added to prevent entering this function
and returning appropriate error code.
Basic manual testing was performed.
Reported-by: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12231
Signed-off-by: Toms Atteka <cpp.code.lv@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Currently OVS supports all ARP protocol fields as OXM match fields to
implement the relevant ARP procedures for IPv4. This includes support
for matching copying and setting ARP fields. In IPv6 ARP has been
replaced by ICMPv6 neighbor discovery (ND) procedures, neighbor
advertisement and neighbor solicitation.
The support for ICMPv6 fields in OVS is not complete for the use cases
equivalent to ARP in IPv4. OVS lacks support for matching, copying and
setting the “ND option type” and “ND reserved” fields. Without these user
cannot implement all ICMPv6 ND procedures for IPv6 support.
This commit adds additional OXM fields to OVS for ICMPv6 “ND option type“
and ICMPv6 “ND reserved” using the OXM extension mechanism. This allows
support for parsing these fields from an ICMPv6 packet header and extending
the OpenFlow protocol with specifications for these new OXM fields for
matching, copying and setting.
Signed-off-by: Vishal Deep Ajmera <vishal.deep.ajmera@ericsson.com>
Co-authored-by: Ashvin Lakshmikantha <ashvin.lakshmikantha@ericsson.com>
Signed-off-by: Ashvin Lakshmikantha <ashvin.lakshmikantha@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
`encap = nl_msg_start_nested(key, OVS_KEY_ATTR_ENCAP)` ensures that
key->size >= (encap + NLA_HDRLEN), so the `if` statement is safe.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11306
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
A masked NSH set action has mdtype 0 because the mdtype is not being
changed, but odp_nsh_key_from_attr() rejects this because mdtype 0 does
not match up with the OVS_NSH_KEY_ATTR_MD1 attribute being present. This
fixes the problem.
The kernel datapath in flow_netlink function nsh_key_put_from_nlattr() has
a similar exception.
Acked-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Test 854 "tunnel_push_pop - action" showed problems in revalidation for
L3 protocol support in its L3 GRE test. L3 packets (that is, packets
without an Ethernet header but only some L3 protocol such as IPv4 or IPv6)
have an Ethernet type that is kept in the dl_type member of the flow, and
the flows that they pass through can cause L3 and L4 fields to be matched.
However, the translation process incorrectly forced the dl_type to be
wildcarded, which caused a contradiction since it's not possible to match
on L3 and L4 fields if the dl_type is not known, and the code in
odp_flow_key_to_flow() and related functions therefore rejected these flows
at revalidation time.
This commit fixes the problem by treating dl_type the same for L2 and L3
flows in translation. It also makes odp_flow_key_to_flow__() copy the
Ethernet type that comes from a packet_type field into dl_type, which is
the expected behavior.
The actual error that this fixes is only visible after applying an upcoming
commit that improves logging for bad datapath flows.
Acked-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
A problem the userspace datapath failed to create a new datapath flow
when dealing with QinQ packets(the flow includeing ip,udp,etc). L2-L5
header should be considered before parsing the second 802.1Q header.
Fixes: f0fb825a3785 ("Add support for 802.1ad (QinQ tunneling)")
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
In this piece of code, 'struct ofpbuf b' should always point to
metadata so that metadata can be filled with values through ofpbuf
operations, like ofpbuf_put_hex and ofpbuf_push_zeros. However,
ofpbuf_push_zeros may change the data pointer of 'struct ofpbuf b'
and therefore, metadata will not contain the expected values.
This patch fixes it by changing ofpbuf_push_zeros to
ofpbuf_put_zeros.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10863
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Oss-fuzz complains that (struct user_action_cookie)->controller->dont_send
has invalid vlue, like below:
runtime error: load of value 26, which is not a valid value for type 'bool'
From this piece of code "cookie.controller.dont_send ? 1 : 0", it looks
like that we want to tolerate values than 0 and 1.
Thus, this patch changes the types of dont_send and continuation from bool
to uint8_t in order to make oss-fuzz happy.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11330
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Despite of linux, 'strtoull' on FreeBSD sets errno to EINVAL in case
of no digits found. This causes odp_flow parsing failure if
there is no geneve data inside it. For example, ovs fails to parse
following flow on FreeBSD:
tunnel(<...>,geneve({class=0xffff,type=1,len=0}),<...>)
Moving the parsing attempt under the if condition fixes the following
unit test failure:
tunnel.at:780: testing tunnel - Geneve option present ...
./tunnel.at:810: ovs-appctl ofproto/trace ovs-dummy \
'tunnel(<...>,geneve({class=0xffff,type=1,len=0}), ...'
--- /dev/null 2018-12-18 13:24:55.001110000 +0000
+++ /tmp/cirrus-ci-build/tests/testsuite.dir/at-groups/848/stderr
@@ -0,0 +1,2 @@
+ovs-dummy: unknown bridge
+ovs-appctl: ovs-vswitchd: server returned an error
CC: Jesse Gross <jesse@kernel.org>
Fixes: 622a0a8e764d ("odp-util: Geneve netlink decoding.")
Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Oss-fuzz complains that 'vid << VLAN_VID_SHIFT' is causing an error of
"Undefined-shift in parse_odp_action". This is because an invalid
value of vid is passed in push_vlan. This patch adds validation to
the value of vid, in addition to the value of pcp.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11520
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Previously, the buffer size of 'struct ofpbuf b' is less than the
size of 'char buf[512]', this could cause memory overflow of ofpbuf
when calling ofpbuf_put_hex. This patch fixes it.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10865
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch puts a limit on the nested depth in flow key string to avoid
stackoverflow. An example to show this issue is a key string contains
thousands of nested encaps. In addition, a new test is added for this fix.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11149
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds validation of close-braces in scan_geneve. An simple
example is "set(encap(tunnel(geneve({{))))". When scan_geneve returns,
(struct geneve_scan *key)->len equals to 2*sizeof(struct geneve_opt).
That seems not correct.
Found this issue while inspecting oss-fuzz
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11153.
In addition, SCAN_TYPE expects scan_XXX functions to return 0
on errors. This patch inspects all related scan_XXX functions
and fixes their return values.
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Functions like scan_u8, return 0 when they failed to scan the expected
values. Function scan_geneve failed to check this situation. This leads
to using of uninitialized value of opt_len_mask. This patch fixes it
and further inspects and fixes all the problematic places where
the return values of scan_XXX functions are not properly handled.
Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10800
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
When parse_odp_key_mask_attr runs into ufid, it returns length of ufid
without further parsing. This causes problem to set action in function
parse_odp_action where nested nlattrs are expected from ofpbuf after.
Since in all callers of parse_odp_key_mask_attr, only odp_flow_from_string
needs to understand ufid. This patch moves ufid parsing from
parse_odp_key_mask_attr out to odp_flow_from_string.
Reported-by: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10850
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
For function odp_nsh_hdr_from_attr, paramemter `attr` may not contain
all necessary OVS_NSH_KEY_ATTR_ to fully initialize data of nsh_hdr.
On return, nsh_hdr can contain uninitialized values in its fields.
This patch zeroes out nsh_hdr in the beginning in order to prevent it.
Reported-by: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10863
Signed-off-by: Yifeng Sun <pkusunyifeng@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The ipv6_label field member of struct ovs_key_ipv6 is 32 bits in size,
but an IPv6 label is only 20 bits, so the upper 12 bits are not writable
and must be 0 in the mask. The code wasn't careful about this so it could
try to write them anyway. This commit fixes the problem.
Reported-by: nm_r@directbox.com
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-September/047357.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
The current implementation of the "dp_hash" selection method suffers
from two deficiences: 1. The hash mask and hence the number of dp_hash
values is just large enough to cover the number of group buckets, but
does not consider the case that buckets have different weights. 2. The
xlate-time selection of best bucket from the masked dp_hash value often
results in bucket load distributions that are quite different from the
bucket weights because the number of available masked dp_hash values
is too small (2-6 bits compared to 32 bits of a full hash in the default
hash selection method).
This commit provides a more accurate implementation of the dp_hash
select group by applying the well known Webster method for distributing
a small number of "seats" fairly over the weighted "parties"
(see https://en.wikipedia.org/wiki/Webster/Sainte-Lagu%C3%AB_method).
The dp_hash mask is autmatically chosen large enough to provide good
enough accuracy even with widely differing weights.
This distribution happens at group modification time and the resulting
table is stored with the group-dpif struct. At xlation time, we use the
masked dp_hash values as index to look up the assigned bucket.
If the bucket should not be live, we do a circular search over the
mapping table until we find the first live bucket. As the buckets in
the table are by construction in pseudo-random order with a frequency
according to their weight, this method maintains correct distribution
even if one or more buckets are non-live.
Xlation is further simplified by storing some derived select group state
at group construction in struct group-dpif in a form better suited for
xlation purposes.
Adapted the unit test case for dp_hash select group accordingly.
Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com>
Signed-off-by: Nitin Katiyar <nitin.katiyar@ericsson.com>
Co-authored-by: Nitin Katiyar <nitin.katiyar@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Instead of memcpy to a local stack, parse the erspan
metadata in memory.
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Add handlers for OVS_VPORT_TYPE_IP6GRE
Cc: Ben Pfaff <blp@ovn.org>
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: William Tu <u9012063@gmail.com>
ERSPAN is a tunneling protocol based on GRE tunnel. The patch
add erspan tunnel support for ovs-vswitchd with userspace datapath.
Configuring erspan tunnel is similar to gre tunnel, but with
additional erspan's parameters. Matching a flow on erspan's
metadata is also supported, see ovs-fields for more details.
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Upstream commit:
commit fc1372f89ffe1f58b589643b75f679e452350703
Author: William Tu <u9012063@gmail.com>
Date: Thu Jan 25 13:20:11 2018 -0800
openvswitch: add erspan version I and II support
The patch adds support for openvswitch to configure erspan
v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added
to uapi as a binary blob to support all ERSPAN v1 and v2's
fields. Note that Previous commit "openvswitch: Add erspan tunnel
support." was reverted since it does not design properly.
Signed-off-by: William Tu <u9012063@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: William Tu <u9012063@gmail.com>
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: William Tu <u9012063@gmail.com>
When there is a flow rule which forwards a packet from geneve
port to another tunnel port, ex: gre, the tun_metadata carried
from the geneve port might affect the outgoing port. For example,
the datapath action from geneve port output to gre port (1) shows:
set(tunnel(tun_id=0x7b,dst=2.2.2.2,ttl=64,
geneve({class=0xffff,type=0,len=4,0x123}),flags(df|key))),1
Where the geneve(...) should not exist.
When using kernel's tunnel port, this triggers an error saying:
"Multiple metadata blocks provided", when there is a rule forwarding
the geneve packet to vxlan/erspan tunnel port. A userspace test case
using geneve and gre also demonstrates the issue.
The patch makes the tun_key_to_attr aware of the tunnel type. So only
the relevant output tunnel's options are set.
Reported-by: Xiaoyan Jin <xiaoyanj@vmware.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Cc: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
For tunnels, TOS ECN bits are never wildcard for the reason that they
are always inherited. OVS will create a rewrite action if we add rule
to modify other IP headers. But it also adds an extra ECN rewrite for
the action because of this ECN un-wildcarding.
It seems no error because the ECN bits to be changed are same in this
case. But as rule can't be offloaded to hardware, the unnecssary ECN
rewrite should be removed.
Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
Reviewed-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
When the same encap() header was pushed twice onto a packet (e.g in the
case of NSH in NSH), the translation logic only generated a datapath push
action for the first encap() action. The second encap() did not emit a
push action because the packet type was unchanged.
commit_encap_decap_action() (renamed from commit_packet_type_change) must
solely rely on ctx->pending_encap to generate an datapath push action.
Similarly, the first decap() action on a double header packet does not
change the packet_type either. Add a corresponding ctx->pending_decap
flag and use that to trigger emitting a datapath pop action.
Fixes: f839892a2 ("OF support and translation of generic encap and decap")
Fixes: 1fc11c594 ("Generic encap and decap support for NSH")
Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
OVS datapaths have two different ways to indicate what kind of packet a
flow matches. One way, used by the userspace datapath, is
OVS_KEY_ATTR_PACKET_TYPE. Another way, used by the kernel datapath, is
OVS_KEY_ATTR_ETHERTYPE when used in the absence of OVS_KEY_ATTR_ETHERNET;
when the latter is present, the packet is always an Ethernet packet. The
code to print datapath flows wasn't paying attention to this distinction
and always omitted eth() from the output when OVS_KEY_ATTR_ETHERNET was
fully wildcarded, which meant that upon later re-parsing the
OVS_KEY_ATTR_ETHERNET key was omitted, which made it look like a
non-Ethernet match was being described.
This commit makes odp_util_format() add eth() to the output when
OVS_KEY_ATTR_ETHERNET is present and OVS_KEY_ATTR_PACKET_TYPE is absent,
avoiding the problem.
Reported-by: Amar Padmanabhan <amarpadmanabhan@fb.com>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2017-December/045817.html
Reported-by: Su Wang <suwang@vmware.com>
VMWare-BZ: #2070488
Signed-off-by: Ben Pfaff <blp@ovn.org>
Tested-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Yi-Hung Wei <yihung.wei@gmail.com>
OVS datapaths don't understand or parse IGMP fields, but OVS userspace
does, so this commit updates odp_flow_key_to_flow() to report that properly
to the caller.
Reported-by: Huanle Han <hanxueluo@gmail.com>
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2018-January/343665.html
Signed-off-by: Ben Pfaff <blp@ovn.org>
The ovs_assert() macro always evaluates its argument, even when NDEBUG is
defined so that failure is ignored. This behavior wasn't documented, and
thus a lot of code didn't rely on it. This commit documents the behavior
and simplifies bits of code that heretofore didn't rely on it.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Reviewed-by: Yifeng Sun <pkusunyifeng@gmail.com>
This supports using the ct_clear action in the kernel datapath. To
preserve compatibility with current ct_clear behavior on old kernels, we
only pass this action down to the datapath if a probe reveals the
datapath actually supports it.
Signed-off-by: Eric Garver <e@erig.me>
Acked-by: William Tu <u9012063@gmail.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
The result of a ternary operation will be promoted at least to int type.
As such, the compiler may generate a warning as: format specifies type
'unsigned char' but the argument has type 'int'
Found with Apple LLVM version 8.1.0 (clang-802.0.42).
Squelch this by preferring the %d format specifier to print 1/0 values.
Fixes: 74c4530dca93 ("ofproto-dpif: Don't slow-path controller actions with pause.")
Cc: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Aaron Conole <aconole@bytheb.org>
Acked-by: Ian Stokes <ian.stokes@intel.com>
Tested-by: Ian Stokes <ian.stokes@intel.com>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
NSH kernel implementation used nested mask for OVS_KEY_ATTR_NSH,
so NSH userspace must adapt to it, OVS hasn't used nested mask for
any key attribute so far, OVS_KEY_ATTR_NSH is the first use case.
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Sparse complains with warning: incorrect type in argument 1 (different
base types) in function parse_odp_userspace_action due to a call to
htonll(rule_cookie). The variable is read in host-byte order, so it
shouldn't have been declared as big-endian.
Fixes: d39ec23de384 ("ofproto-dpif: Don't slow-path controller actions.")
Reported-by: Ian Stokes <ian.stokes@intel.com>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ian Stokes <ian.stokes@intel.com>
Tested-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Ben Pfaff <blp@ovn.org>
IETF NSH draft added a new filed ttl in NSH header, this patch
is to add new nsh key 'ttl' for it.
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
A previous patch removed slow-pathing for controller actions with the
exception of ones that specified "pause". This commit removes that
restriction so that no controller actions are slow-pathed.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Controller actions have become more commonly used for purposes other
than just making forwarding decisions (e.g., packet logging). A packet
that needs to be copied to the controller and forwarded would always be
sent to ovs-vswitchd to be handled, which could negatively affect
performance and cause heavier CPU utilization in ovs-vswitchd.
This commit changes the behavior so that OpenFlow controller actions
become userspace datapath actions while continuing to let packet
forwarding and manipulation continue to be handled by the datapath
directly.
This patch still slow-paths controller actions with the "pause" flag
set. A future patch will stop slow-pathing these pause actions as
well.
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Previously, the ofproto instance and OpenFlow port have been derived
based on the datapath port number. This change explicitly declares them
both, which will be helpful in future commits that no longer can depend
on having a unique datapath port (e.g., a source port that represents
the controller).
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
This patch changes OVS_KEY_ATTR_NSH
to nested attribute and adds three new NSH sub attribute keys:
OVS_NSH_KEY_ATTR_BASE: for length-fixed NSH base header
OVS_NSH_KEY_ATTR_MD1: for length-fixed MD type 1 context
OVS_NSH_KEY_ATTR_MD2: for length-variable MD type 2 metadata
Its intention is to align to NSH kernel implementation.
NSH match fields, set and PUSH_NSH action all use the below
nested attribute format:
OVS_KEY_ATTR_NSH begin
OVS_NSH_KEY_ATTR_BASE
OVS_NSH_KEY_ATTR_MD1
OVS_KEY_ATTR_NSH end
or
OVS_KEY_ATTR_NSH begin
OVS_NSH_KEY_ATTR_BASE
OVS_NSH_KEY_ATTR_MD2
OVS_KEY_ATTR_NSH end
In addition, NSH encap and decap actions are renamed as push_nsh
and pop_nsh to meet action naming convention.
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
FreeBSD insists that <sys/types.h> be included before <netinet/in.h> and
that <netinet/in.h> be included before <arpa/inet.h>. This adds guards to
the "sparse" headers to yield a warning if this order is violated. This
commit also adjusts the order of many #includes to suit this requirement.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
The 'mask' buffer in parse_odp_action() is supposed to always be big
enough:
/* 'mask' is big enough to hold any key. */
Geneve options can be really big and the comment was wrong. In addition,
the user might supply more options than can really fit in any case, so
we might as well just use a stub.
Found by libfuzzer.
Reported-by: Bhargava Shastry <bshastry@sec.t-labs.tu-berlin.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
These lines of code are intended to copy the 'next' and 'next_max' members
of tbl[type] into local variables 'tbl' and 'max':
tbl = tbl[type].next;
max = tbl[type].next_max;
They didn't do it properly because the first line changes 'tbl', so that
the first and seconds lines' references to tbl[type] refer to different
objects.
This commit fixes the problem.
Found by libfuzzer.
Reported-by: Bhargava Shastry <bshastry@sec.t-labs.tu-berlin.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
