2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00
ovs/lib/odp-util.h

346 lines
16 KiB
C
Raw Normal View History

/*
* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef ODP_UTIL_H
#define ODP_UTIL_H 1
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <string.h>
#include "flow.h"
#include "hash.h"
#include "openvswitch/hmap.h"
#include "openvswitch/ofp-actions.h"
#include "odp-netlink.h"
#include "openflow/openflow.h"
#include "util.h"
struct ds;
struct nlattr;
struct ofpbuf;
struct simap;
struct pkt_metadata;
#define SLOW_PATH_REASONS \
/* These reasons are mutually exclusive. */ \
SPR(SLOW_CFM, "cfm", "Consists of CFM packets") \
SPR(SLOW_BFD, "bfd", "Consists of BFD packets") \
SPR(SLOW_LACP, "lacp", "Consists of LACP packets") \
SPR(SLOW_STP, "stp", "Consists of STP packets") \
SPR(SLOW_LLDP, "lldp", "Consists of LLDP packets") \
SPR(SLOW_CONTROLLER, "controller", \
"Sends \"packet-in\" messages to the OpenFlow controller") \
SPR(SLOW_ACTION, "action", \
"Uses action(s) not supported by datapath")
/* Indexes for slow-path reasons. Client code uses "enum slow_path_reason"
* values instead of these, these are just a way to construct those. */
enum {
#define SPR(ENUM, STRING, EXPLANATION) ENUM##_INDEX,
SLOW_PATH_REASONS
#undef SPR
};
/* Reasons why a subfacet might not be fast-pathable.
*
* Each reason is a separate bit to allow reasons to be combined. */
enum slow_path_reason {
#define SPR(ENUM, STRING, EXPLANATION) ENUM = 1 << ENUM##_INDEX,
SLOW_PATH_REASONS
#undef SPR
};
/* Mask of all slow_path_reasons. */
enum {
SLOW_PATH_REASON_MASK = 0
#define SPR(ENUM, STRING, EXPLANATION) | 1 << ENUM##_INDEX
SLOW_PATH_REASONS
#undef SPR
};
const char *slow_path_reason_to_explanation(enum slow_path_reason);
#define ODPP_LOCAL ODP_PORT_C(OVSP_LOCAL)
#define ODPP_NONE ODP_PORT_C(UINT32_MAX)
void format_odp_actions(struct ds *, const struct nlattr *odp_actions,
size_t actions_len, const struct hmap *portno_names);
int odp_actions_from_string(const char *, const struct simap *port_names,
struct ofpbuf *odp_actions);
/* A map from odp port number to its name. */
struct odp_portno_names {
struct hmap_node hmap_node; /* A node in a port number to name hmap. */
odp_port_t port_no; /* Port number in the datapath. */
char *name; /* Name associated with the above 'port_no'. */
};
void odp_portno_names_set(struct hmap *portno_names, odp_port_t port_no,
char *port_name);
void odp_portno_names_destroy(struct hmap *portno_names);
void odp_portno_name_format(const struct hmap *portno_names,
odp_port_t, struct ds *);
/* The maximum number of bytes that odp_flow_key_from_flow() appends to a
* buffer. This is the upper bound on the length of a nlattr-formatted flow
* key that ovs-vswitchd fully understands.
*
* OVS doesn't insist that ovs-vswitchd and the datapath have exactly the same
* idea of a flow, so therefore this value isn't necessarily an upper bound on
* the length of a flow key that the datapath can pass to ovs-vswitchd.
*
* The longest nlattr-formatted flow key appended by odp_flow_key_from_flow()
* would be:
*
* struct pad nl hdr total
* ------ --- ------ -----
* OVS_KEY_ATTR_PRIORITY 4 -- 4 8
* OVS_KEY_ATTR_TUNNEL 0 -- 4 4
* - OVS_TUNNEL_KEY_ATTR_ID 8 -- 4 12
* - OVS_TUNNEL_KEY_ATTR_IPV4_SRC 4 -- 4 8
* - OVS_TUNNEL_KEY_ATTR_IPV4_DST 4 -- 4 8
* - OVS_TUNNEL_KEY_ATTR_IPV6_SRC 16 -- 4 20
* - OVS_TUNNEL_KEY_ATTR_IPV6_DST 16 -- 4 20
* - OVS_TUNNEL_KEY_ATTR_TOS 1 3 4 8
* - OVS_TUNNEL_KEY_ATTR_TTL 1 3 4 8
* - OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT 0 -- 4 4
* - OVS_TUNNEL_KEY_ATTR_CSUM 0 -- 4 4
* - OVS_TUNNEL_KEY_ATTR_OAM 0 -- 4 4
* - OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS 256 -- 4 260
* - OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS - -- - - (shared with _GENEVE_OPTS)
* OVS_KEY_ATTR_IN_PORT 4 -- 4 8
* OVS_KEY_ATTR_SKB_MARK 4 -- 4 8
* OVS_KEY_ATTR_DP_HASH 4 -- 4 8
* OVS_KEY_ATTR_RECIRC_ID 4 -- 4 8
Add support for connection tracking. This patch adds a new action and fields to OVS that allow connection tracking to be performed. This support works in conjunction with the Linux kernel support merged into the Linux-4.3 development cycle. Packets have two possible states with respect to connection tracking: Untracked packets have not previously passed through the connection tracker, while tracked packets have previously been through the connection tracker. For OpenFlow pipeline processing, untracked packets can become tracked, and they will remain tracked until the end of the pipeline. Tracked packets cannot become untracked. Connections can be unknown, uncommitted, or committed. Packets which are untracked have unknown connection state. To know the connection state, the packet must become tracked. Uncommitted connections have no connection state stored about them, so it is only possible for the connection tracker to identify whether they are a new connection or whether they are invalid. Committed connections have connection state stored beyond the lifetime of the packet, which allows later packets in the same connection to be identified as part of the same established connection, or related to an existing connection - for instance ICMP error responses. The new 'ct' action transitions the packet from "untracked" to "tracked" by sending this flow through the connection tracker. The following parameters are supported initally: - "commit": When commit is executed, the connection moves from uncommitted state to committed state. This signals that information about the connection should be stored beyond the lifetime of the packet within the pipeline. This allows future packets in the same connection to be recognized as part of the same "established" (est) connection, as well as identifying packets in the reply (rpl) direction, or packets related to an existing connection (rel). - "zone=[u16|NXM]": Perform connection tracking in the zone specified. Each zone is an independent connection tracking context. When the "commit" parameter is used, the connection will only be committed in the specified zone, and not in other zones. This is 0 by default. - "table=NUMBER": Fork pipeline processing in two. The original instance of the packet will continue processing the current actions list as an untracked packet. An additional instance of the packet will be sent to the connection tracker, which will be re-injected into the OpenFlow pipeline to resume processing in the specified table, with the ct_state and other ct match fields set. If the table is not specified, then the packet is submitted to the connection tracker, but the pipeline does not fork and the ct match fields are not populated. It is strongly recommended to specify a table later than the current table to prevent loops. When the "table" option is used, the packet that continues processing in the specified table will have the ct_state populated. The ct_state may have any of the following flags set: - Tracked (trk): Connection tracking has occurred. - Reply (rpl): The flow is in the reply direction. - Invalid (inv): The connection tracker couldn't identify the connection. - New (new): This is the beginning of a new connection. - Established (est): This is part of an already existing connection. - Related (rel): This connection is related to an existing connection. For more information, consult the ovs-ofctl(8) man pages. Below is a simple example flow table to allow outbound TCP traffic from port 1 and drop traffic from port 2 that was not initiated by port 1: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,ct_state=-trk,action=ct(commit,zone=9),2 table=0,in_port=2,tcp,ct_state=-trk,action=ct(zone=9,table=1) table=1,in_port=2,ct_state=+trk+est,tcp,action=1 table=1,in_port=2,ct_state=+trk+new,tcp,action=drop Based on original design by Justin Pettit, contributions from Thomas Graf and Daniele Di Proietto. Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
2015-08-11 10:56:09 -07:00
* OVS_KEY_ATTR_CT_STATE 4 -- 4 8
* OVS_KEY_ATTR_CT_ZONE 2 2 4 8
* OVS_KEY_ATTR_CT_MARK 4 -- 4 8
* OVS_KEY_ATTR_CT_LABEL 16 -- 4 20
* OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6 40 -- 4 44
* OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 - -- - - (exclusive of_CT_ORIG_TUPLE_IPV6)
* OVS_KEY_ATTR_ETHERNET 12 -- 4 16
* OVS_KEY_ATTR_ETHERTYPE 2 2 4 8 (outer VLAN ethertype)
* OVS_KEY_ATTR_VLAN 2 2 4 8
* OVS_KEY_ATTR_ENCAP 0 -- 4 4 (VLAN encapsulation)
* OVS_KEY_ATTR_ETHERTYPE 2 2 4 8 (inner VLAN ethertype)
* OVS_KEY_ATTR_IPV6 40 -- 4 44
* OVS_KEY_ATTR_ICMPV6 2 2 4 8
* OVS_KEY_ATTR_ND 28 -- 4 32
* ----------------------------------------------------------
* total 616
*
* We include some slack space in case the calculation isn't quite right or we
* add another field and forget to adjust this value.
*/
#define ODPUTIL_FLOW_KEY_BYTES 640
userspace: Add packet_type in dp_packet and flow This commit adds a packet_type attribute to the structs dp_packet and flow to explicitly carry the type of the packet as prepration for the introduction of the so-called packet type-aware pipeline (PTAP) in OVS. The packet_type is a big-endian 32 bit integer with the encoding as specified in OpenFlow verion 1.5. The upper 16 bits contain the packet type name space. Pre-defined values are defined in openflow-common.h: enum ofp_header_type_namespaces { OFPHTN_ONF = 0, /* ONF namespace. */ OFPHTN_ETHERTYPE = 1, /* ns_type is an Ethertype. */ OFPHTN_IP_PROTO = 2, /* ns_type is a IP protocol number. */ OFPHTN_UDP_TCP_PORT = 3, /* ns_type is a TCP or UDP port. */ OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */ }; The lower 16 bits specify the actual type in the context of the name space. Only name spaces 0 and 1 will be supported for now. For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet). This is the default packet_type in OVS and the only one supported so far. Packets of type (OFPHTN_ONF, 0) are called Ethernet packets. In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet. A packet of type (OFPHTN_ETHERTYPE, <Ethertype>) is a standard L2 packet whith the Ethernet header (and any VLAN tags) removed to expose the L3 (or L2.5) payload of the packet. These will simply be called L3 packets. The Ethernet address fields dl_src and dl_dst in struct flow are not applicable for an L3 packet and must be zero. However, to maintain compatibility with the large code base, we have chosen to copy the Ethertype of an L3 packet into the the dl_type field of struct flow. This does not mean that it will be possible to match on dl_type for L3 packets with PTAP later on. Matching must be done on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-04-25 16:29:59 +00:00
BUILD_ASSERT_DECL(FLOW_WC_SEQ == 39);
/* A buffer with sufficient size and alignment to hold an nlattr-formatted flow
* key. An array of "struct nlattr" might not, in theory, be sufficiently
* aligned because it only contains 16-bit types. */
struct odputil_keybuf {
uint32_t keybuf[DIV_ROUND_UP(ODPUTIL_FLOW_KEY_BYTES, 4)];
};
tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis. When using tunnel TLVs (at the moment, this means Geneve options), a controller must first map the class and type onto an appropriate OXM field so that it can be used in OVS flow operations. This table is managed using OpenFlow extensions. The original code that added support for TLVs made the mapping table global as a simplification. However, this is not really logically correct as the OpenFlow management commands are operating on a per-bridge basis. This removes the original limitation to make the table per-bridge. One nice result of this change is that it is generally clearer whether the tunnel metadata is in datapath or OpenFlow format. Rather than allowing ad-hoc format changes and trying to handle both formats in the tunnel metadata functions, the format is more clearly separated by function. Datapaths (both kernel and userspace) use datapath format and it is not changed during the upcall process. At the beginning of action translation, tunnel metadata is converted to OpenFlow format and flows and wildcards are translated back at the end of the process. As an additional benefit, this change improves performance in some flow setup situations by keeping the tunnel metadata in the original packet format in more cases. This helps when copies need to be made as the amount of data touched is only what is present in the packet rather than the maximum amount of metadata supported. Co-authored-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Jesse Gross <jesse@kernel.org> Acked-by: Ben Pfaff <blp@ovn.org>
2016-04-19 18:36:04 -07:00
enum odp_key_fitness odp_tun_key_from_attr(const struct nlattr *,
struct flow_tnl *);
int odp_ufid_from_string(const char *s_, ovs_u128 *ufid);
void odp_format_ufid(const ovs_u128 *ufid, struct ds *);
tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis. When using tunnel TLVs (at the moment, this means Geneve options), a controller must first map the class and type onto an appropriate OXM field so that it can be used in OVS flow operations. This table is managed using OpenFlow extensions. The original code that added support for TLVs made the mapping table global as a simplification. However, this is not really logically correct as the OpenFlow management commands are operating on a per-bridge basis. This removes the original limitation to make the table per-bridge. One nice result of this change is that it is generally clearer whether the tunnel metadata is in datapath or OpenFlow format. Rather than allowing ad-hoc format changes and trying to handle both formats in the tunnel metadata functions, the format is more clearly separated by function. Datapaths (both kernel and userspace) use datapath format and it is not changed during the upcall process. At the beginning of action translation, tunnel metadata is converted to OpenFlow format and flows and wildcards are translated back at the end of the process. As an additional benefit, this change improves performance in some flow setup situations by keeping the tunnel metadata in the original packet format in more cases. This helps when copies need to be made as the amount of data touched is only what is present in the packet rather than the maximum amount of metadata supported. Co-authored-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Madhu Challa <challa@noironetworks.com> Signed-off-by: Jesse Gross <jesse@kernel.org> Acked-by: Ben Pfaff <blp@ovn.org>
2016-04-19 18:36:04 -07:00
void odp_flow_format(const struct nlattr *key, size_t key_len,
const struct nlattr *mask, size_t mask_len,
const struct hmap *portno_names, struct ds *,
bool verbose);
void odp_flow_key_format(const struct nlattr *, size_t, struct ds *);
int odp_flow_from_string(const char *s,
const struct simap *port_names,
struct ofpbuf *, struct ofpbuf *);
/* ODP_SUPPORT_FIELD(TYPE, FIELD_NAME, FIELD_DESCRIPTION)
*
* Each 'ODP_SUPPORT_FIELD' defines a member in 'struct odp_support',
* and represents support for related OVS_KEY_ATTR_* fields.
* They are defined as macros to keep 'dpif_show_support()' in sync
* as new fields are added. */
#define ODP_SUPPORT_FIELDS \
/* Maximum number of 802.1q VLAN headers to serialize in a mask. */ \
ODP_SUPPORT_FIELD(size_t, max_vlan_headers, "Max VLAN headers") \
/* Maximum number of MPLS label stack entries to serialise in a mask. */ \
ODP_SUPPORT_FIELD(size_t, max_mpls_depth, "Max MPLS depth") \
/* If this is true, then recirculation fields will always be \
* serialised. */ \
ODP_SUPPORT_FIELD(bool, recirc, "Recirc") \
/* If true, serialise the corresponding OVS_KEY_ATTR_CONN_* field. */ \
ODP_SUPPORT_FIELD(bool, ct_state, "CT state") \
ODP_SUPPORT_FIELD(bool, ct_zone, "CT zone") \
ODP_SUPPORT_FIELD(bool, ct_mark, "CT mark") \
ODP_SUPPORT_FIELD(bool, ct_label, "CT label") \
\
/* If true, it means that the datapath supports the NAT bits in \
* 'ct_state'. The above 'ct_state' member must be true for this \
* to make sense */ \
ODP_SUPPORT_FIELD(bool, ct_state_nat, "CT state NAT") \
\
/* Conntrack original direction tuple matching * supported. */ \
ODP_SUPPORT_FIELD(bool, ct_orig_tuple, "CT orig tuple") \
ODP_SUPPORT_FIELD(bool, ct_orig_tuple6, "CT orig tuple for IPv6")
/* Indicates support for various fields. This defines how flows will be
* serialised. */
struct odp_support {
#define ODP_SUPPORT_FIELD(TYPE, NAME, TITLE) TYPE NAME;
ODP_SUPPORT_FIELDS
#undef ODP_SUPPORT_FIELD
};
struct odp_flow_key_parms {
/* The flow and mask to be serialized. In the case of masks, 'flow'
* is used as a template to determine how to interpret 'mask'. For
* example, the 'dl_type' of 'mask' describes the mask, but it doesn't
* indicate whether the other fields should be interpreted as ARP, IPv4,
* IPv6, etc. */
const struct flow *flow;
const struct flow *mask;
/* Indicates support for various fields. If the datapath supports a field,
* then it will always be serialised. */
struct odp_support support;
/* Indicates if we are probing datapath capability. If true, ignore the
* configured flow limits. */
bool probe;
/* The netlink formatted version of the flow. It is used in cases where
* the mask cannot be constructed from the OVS internal representation
* and needs to see the original form. */
const struct ofpbuf *key_buf;
};
void odp_flow_key_from_flow(const struct odp_flow_key_parms *, struct ofpbuf *);
void odp_flow_key_from_mask(const struct odp_flow_key_parms *, struct ofpbuf *);
uint32_t odp_flow_key_hash(const struct nlattr *, size_t);
/* Estimated space needed for metadata. */
enum { ODP_KEY_METADATA_SIZE = 9 * 8 };
userspace: Switching of L3 packets in L2 pipeline Ports have a new layer3 attribute if they send/receive L3 packets. The packet_type included in structs dp_packet and flow is considered in ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and vlan_tci, vlan_vid, vlan_pcp) now have Ethernet as pre-requisite. A dummy ethernet header is pushed to L3 packets received from L3 ports before the the pipeline processing starts. The ethernet header is popped before sending a packet to a L3 port. For datapath ports that can receive L2 or L3 packets, the packet_type becomes part of the flow key for datapath flows and is handled appropriately in dpif-netdev. In the 'else' branch in flow_put_on_pmd() function, the additional check flow_equal(&match.flow, &netdev_flow->flow) was removed, as a) the dpcls lookup is sufficient to uniquely identify a flow and b) it caused false negatives because the flow in netdev->flow may not properly masked. In dpif_netdev_flow_put() we now use the same method for constructing the netdev_flow_key as the one used when adding the flow to the dplcs to make sure these always match. The function netdev_flow_key_from_flow() used so far was not only inefficient but sometimes caused mismatches and subsequent flow update failures. The kernel datapath does not support the packet_type match field. Instead it encodes the packet type implictly by the presence or absence of the Ethernet attribute in the flow key and mask. This patch filters the PACKET_TYPE attribute out of netlink flow key and mask to be sent to the kernel datapath. Signed-off-by: Lorand Jakab <lojakab@cisco.com> Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Yi Yang <yi.y.yang@intel.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2017-06-02 16:16:17 +00:00
void odp_key_from_dp_packet(struct ofpbuf *, const struct dp_packet *);
void odp_key_to_dp_packet(const struct nlattr *key, size_t key_len,
struct dp_packet *md);
/* How well a kernel-provided flow key (a sequence of OVS_KEY_ATTR_*
* attributes) matches OVS userspace expectations.
*
* These values are arranged so that greater values are "more important" than
* lesser ones. In particular, a single flow key can fit the descriptions for
* both ODP_FIT_TOO_LITTLE and ODP_FIT_TOO_MUCH. Such a key is treated as
* ODP_FIT_TOO_LITTLE. */
enum odp_key_fitness {
ODP_FIT_PERFECT, /* The key had exactly the fields we expect. */
ODP_FIT_TOO_MUCH, /* The key had fields we don't understand. */
ODP_FIT_TOO_LITTLE, /* The key lacked fields we expected to see. */
ODP_FIT_ERROR, /* The key was invalid. */
};
enum odp_key_fitness odp_flow_key_to_flow(const struct nlattr *, size_t,
struct flow *);
enum odp_key_fitness odp_flow_key_to_mask(const struct nlattr *mask_key,
size_t mask_key_len,
struct flow_wildcards *mask,
const struct flow *flow);
int parse_key_and_mask_to_match(const struct nlattr *key, size_t key_len,
const struct nlattr *mask, size_t mask_len,
struct match *match);
dpif-netdev: Translate Geneve options per-flow, not per-packet. The kernel implementation of Geneve options stores the TLV option data in the flow exactly as received, without any further parsing. This is then translated to known options for the purposes of matching on flow setup (which will then install a datapath flow in the form the kernel is expecting). The userspace implementation behaves a little bit differently - it looks up known options as each packet is received. The reason for this is there is a much tighter coupling between datapath and flow translation and the representation is generally expected to be the same. This works but it incurs work on a per-packet basis that could be done per-flow instead. This introduces a small translation step for Geneve packets between datapath and flow lookup for the userspace datapath in order to allow the same kind of processing that the kernel does. A side effect of this is that unknown options are now shown when flows dumped via ovs-appctl dpif/dump-flows, similar to the kernel. There is a second benefit to this as well: for some operations it is preferable to keep the options exactly as they were received on the wire, which this enables. One example is that for packets that are executed from ofproto-dpif-upcall to the datapath, this avoids the translation of Geneve metadata. Since this conversion is potentially lossy (for unknown options), keeping everything in the same format removes the possibility of dropping options if the packet comes back up to userspace and the Geneve option translation table has changed. To help with these types of operations, most functions can understand both formats of data and seamlessly do the right thing. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
2015-06-29 18:01:59 -07:00
const char *odp_key_fitness_to_string(enum odp_key_fitness);
void commit_odp_tunnel_action(const struct flow *, struct flow *base,
struct ofpbuf *odp_actions);
void commit_masked_set_action(struct ofpbuf *odp_actions,
enum ovs_key_attr key_type, const void *key,
const void *mask, size_t key_size);
enum slow_path_reason commit_odp_actions(const struct flow *,
struct flow *base,
struct ofpbuf *odp_actions,
struct flow_wildcards *wc,
bool use_masked);
/* ofproto-dpif interface.
*
* The following types and functions are logically part of ofproto-dpif.
* ofproto-dpif puts values of these types into the flows that it installs in
* the kernel datapath, though, so ovs-dpctl needs to interpret them so that
* it can print flows in a more human-readable manner. */
enum user_action_cookie_type {
USER_ACTION_COOKIE_UNSPEC,
USER_ACTION_COOKIE_SFLOW, /* Packet for per-bridge sFlow sampling. */
USER_ACTION_COOKIE_SLOW_PATH, /* Userspace must process this flow. */
USER_ACTION_COOKIE_FLOW_SAMPLE, /* Packet for per-flow sampling. */
USER_ACTION_COOKIE_IPFIX, /* Packet for per-bridge IPFIX sampling. */
};
/* user_action_cookie is passed as argument to OVS_ACTION_ATTR_USERSPACE. */
union user_action_cookie {
uint16_t type; /* enum user_action_cookie_type. */
struct {
uint16_t type; /* USER_ACTION_COOKIE_SFLOW. */
ovs_be16 vlan_tci; /* Destination VLAN TCI. */
uint32_t output; /* SFL_FLOW_SAMPLE_TYPE 'output' value. */
} sflow;
struct {
uint16_t type; /* USER_ACTION_COOKIE_SLOW_PATH. */
uint16_t unused;
uint32_t reason; /* enum slow_path_reason. */
} slow_path;
struct {
uint16_t type; /* USER_ACTION_COOKIE_FLOW_SAMPLE. */
uint16_t probability; /* Sampling probability. */
uint32_t collector_set_id; /* ID of IPFIX collector set. */
uint32_t obs_domain_id; /* Observation Domain ID. */
uint32_t obs_point_id; /* Observation Point ID. */
ipfix: Support tunnel information for Flow IPFIX. Add support to export tunnel information for flow-based IPFIX. The original steps to configure flow level IPFIX: 1) Create a new record in Flow_Sample_Collector_Set table: 'ovs-vsctl -- create Flow_Sample_Collector_Set id=1 bridge="Bridge UUID"' 2) Add IPFIX configuration which is referred by corresponding row in Flow_Sample_Collector_Set table: 'ovs-vsctl -- set Flow_Sample_Collector_Set "Flow_Sample_Collector_Set UUID" ipfix=@i -- --id=@i create IPFIX targets=\"IP:4739\" obs_domain_id=123 obs_point_id=456 cache_active_timeout=60 cache_max_flows=13' 3) Add sample action to the flows: 'ovs-ofctl add-flow mybridge in_port=1, actions=sample'('probability=65535,collector_set_id=1, obs_domain_id=123,obs_point_id=456')',output:3' NXAST_SAMPLE action was used in step 3. In order to support exporting tunnel information, the NXAST_SAMPLE2 action was added and with NXAST_SAMPLE2 action in this patch, the step 3 should be configured like below: 'ovs-ofctl add-flow mybridge in_port=1, actions=sample'('probability=65535,collector_set_id=1,obs_domain_id=123, obs_point_id=456,sampling_port=3')',output:3' 'sampling_port' can be equal to ingress port or one of egress ports. If sampling port is equal to output port and the output port is a tunnel port, OVS_USERSPACE_ATTR_EGRESS_TUN_PORT will be set in the datapath flow sample action. When flow sample action upcall happens, tunnel information will be retrieved from the datapath and then IPFIX can export egress tunnel port information. If samping_port=65535 (OFPP_NONE), flow-based IPFIX will keep the same behavior as before. This patch mainly do three tasks: 1) Add a new flow sample action NXAST_SAMPLE2 to support exporting tunnel information. NXAST_SAMPLE2 action has a new added field 'sampling_port'. 2) Use 'other_configure: enable-tunnel-sampling' to enable or disable exporting tunnel information. 3) If 'sampling_port' is equal to output port and output port is a tunnel port, the translation of OpenFlow "sample" action should first emit set(tunnel(...)), then the sample action itself. It makes sure the egress tunnel information can be sampled. 4) Add a test of flow-based IPFIX for tunnel set. How to test flow-based IPFIX: 1) Setup a test environment with two Linux host with Docker supported 2) Create a Docker container and a GRE tunnel port on each host 3) Use ovs-docker to add the container on the bridge 4) Listen on port 4739 on the collector machine and use wireshark to filter 'cflow' packets. 5) Configure flow-based IPFIX: - 'ovs-vsctl -- create Flow_Sample_Collector_Set id=1 bridge="Bridge UUID"' - 'ovs-vsctl -- set Flow_Sample_Collector_Set "Flow_Sample_Collector_Set UUID" ipfix=@i -- --id=@i create IPFIX \ targets=\"IP:4739\" cache_active_timeout=60 cache_max_flows=13 \ other_config:enable-tunnel-sampling=true' - 'ovs-ofctl add-flow mybridge in_port=1, actions=sample'('probability=65535,collector_set_id=1,obs_domain_id=123, obs_point_id=456,sampling_port=3')',output:3' Note: The in-port is container port. The output port and sampling_port are both open flow port and the output port is a GRE tunnel port. 6) Ping from the container whose host enabled flow-based IPFIX. 7) Get the IPFIX template pakcets and IPFIX information packets. Signed-off-by: Benli Ye <daniely@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-06-14 16:53:34 +08:00
odp_port_t output_odp_port; /* The output odp port. */
enum nx_action_sample_direction direction;
} flow_sample;
struct {
uint16_t type; /* USER_ACTION_COOKIE_IPFIX. */
odp_port_t output_odp_port; /* The output odp port. */
} ipfix;
};
BUILD_ASSERT_DECL(sizeof(union user_action_cookie) == 24);
size_t odp_put_userspace_action(uint32_t pid,
const void *userdata, size_t userdata_size,
odp_port_t tunnel_out_port,
Extend sFlow agent to report tunnel and MPLS structures Packets are still sampled at ingress only, so the egress tunnel and/or MPLS structures are only included when there is just 1 output port. The actions are either provided by the datapath in the sample upcall or looked up in the userspace cache. The former is preferred because it is more reliable and does not present any new demands or constraints on the userspace cache, however the code falls back on the userspace lookup so that this solution can work with existing kernel datapath modules. If the lookup fails it is not critical: the compiled user-action-cookie is still available and provides the essential output port and output VLAN forwarding information just as before. The openvswitch actions can express almost any tunneling/mangling so the only totally faithful representation would be to somehow encode the whole list of flow actions in the sFlow output. However the standard sFlow tunnel structures can express most common real-world scenarios, so in parsing the actions we look for those and skip the encoding if we see anything unusual. For example, a single set(tunnel()) or tnl_push() is interpreted, but if a second such action is encountered then the egress tunnel reporting is suppressed. The sFlow standard allows "best effort" encoding so that if a field is not knowable or too onerous to look up then it can be left out. This is often the case for the layer-4 source port or even the src ip address of a tunnel. The assumption is that monitoring is enabled everywhere so a missing field can typically be seen at ingress to the next switch in the path. This patch also adds unit tests to check the sFlow encoding of set(tunnel()), tnl_push() and push_mpls() actions. The netlink attribute to request that actions be included in the upcall from the datapath is inserted for sFlow sampling only. To make that option be explicit would require further changes to the printing and parsing of actions in lib/odp-util.c, and to scripts in the test suite. Further enhancements to report on 802.1AD QinQ, 64-bit tunnel IDs, and NAT transformations can follow in future patches that make only incremental changes. Signed-off-by: Neil McKee <neil.mckee@inmon.com> [blp@nicira.com made stylistic and semantic changes] Signed-off-by: Ben Pfaff <blp@nicira.com>
2015-07-17 21:37:02 -07:00
bool include_actions,
struct ofpbuf *odp_actions);
void odp_put_tunnel_action(const struct flow_tnl *tunnel,
struct ofpbuf *odp_actions);
void odp_put_tnl_push_action(struct ofpbuf *odp_actions,
struct ovs_action_push_tnl *data);
void odp_put_pop_eth_action(struct ofpbuf *odp_actions);
void odp_put_push_eth_action(struct ofpbuf *odp_actions,
const struct eth_addr *eth_src,
const struct eth_addr *eth_dst);
#endif /* odp-util.h */