summaryrefslogtreecommitdiff
path: root/lib/match.c
Commit message (Collapse)AuthorAgeFilesLines
* match: Add helper function to set nw_ttl with maskPaul Blakey2017-08-111-0/+7
| | | | | | | | | | Add help function match_set_nw_ttl_masked() Will be used later to set ttl value. Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Acked-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Joe Stringer <joe@ovn.org>
* Adding nsh.at for NSH unit testsJan Scheurich2017-08-071-2/+4
| | | | | | | | | | First basic NSH test case implemented and working. Unconditionally show matched packet_type in megaflows, even when matching on eth. Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* userspace: Add support for NSH MD1 match fieldsJan Scheurich2017-08-071-2/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for NSH packet header fields to the OVS control plane and the userspace datapath. Initially we support the fields of the NSH base header as defined in https://www.ietf.org/id/draft-ietf-sfc-nsh-13.txt and the fixed context headers specified for metadata format MD1. The variable length MD2 format is parsed but the TLV context headers are not yet available for matching. The NSH fields are modelled as experimenter fields with the dedicated experimenter class 0x005ad650 proposed for NSH in ONF. The following fields are defined: NXOXM code ofctl name Size Comment ===================================================================== NXOXM_NSH_FLAGS nsh_flags 8 Bits 2-9 of 1st NSH word (0x005ad650,1) NXOXM_NSH_MDTYPE nsh_mdtype 8 Bits 16-23 (0x005ad650,2) NXOXM_NSH_NEXTPROTO nsh_np 8 Bits 24-31 (0x005ad650,3) NXOXM_NSH_SPI nsh_spi 24 Bits 0-23 of 2nd NSH word (0x005ad650,4) NXOXM_NSH_SI nsh_si 8 Bits 24-31 (0x005ad650,5) NXOXM_NSH_C1 nsh_c1 32 Maskable, nsh_mdtype==1 (0x005ad650,6) NXOXM_NSH_C2 nsh_c2 32 Maskable, nsh_mdtype==1 (0x005ad650,7) NXOXM_NSH_C3 nsh_c3 32 Maskable, nsh_mdtype==1 (0x005ad650,8) NXOXM_NSH_C4 nsh_c4 32 Maskable, nsh_mdtype==1 (0x005ad650,9) Co-authored-by: Johnson Li <johnson.li@intel.com> Signed-off-by: Yi Yang <yi.y.yang@intel.com> Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* userspace: Add OXM field MFF_PACKET_TYPEJan Scheurich2017-06-271-31/+67
| | | | | | | | | | | | | | | | | | | | | | | Allow packet type namespace OFPHTN_ETHERTYPE as alternative pre-requisite for matching L3 protocols (MPLS, IP, IPv6, ARP etc). Change the meta-flow definition of packet_type field to use the new custom format MFS_PACKET_TYPE representing "(NS,NS_TYPE)". Parsing routine for MFS_PACKET_TYPE added to meta-flow.c. Formatting routine for field packet_type extracted from match_format() and moved to flow.c to be used from meta-flow.c for formatting MFS_PACKET_TYPE. Updated the ovs-fields man page source meta-flow.xml with documentation for packet-type-aware bridges and added documentation for field packet_type. Added packet_type to the matching properties in tests/ofproto.at. If dl_type is unwildcarded due to later packet modification, make sure it is cleared again if the original packet_type was not PT_ETH. Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* match: Add helper function to set tunnel tp_dstRoi Dayan2017-06-151-0/+13
| | | | | | | | | | Add help function match_set_tun_tp_dst(). Will be used in the next commit. This patch doesn't change any functionality. Signed-off-by: Roi Dayan <roid@mellanox.com> Acked-by: Flavio Leitner <fbl@sysclose.org> Signed-off-by: Simon Horman <simon.horman@netronome.com>
* userspace: Switching of L3 packets in L2 pipelineJan Scheurich2017-06-021-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Support accepting and displaying port names in OVS tools.Ben Pfaff2017-05-311-16/+27
| | | | | | | | | | | | | | Until now, most ovs-ofctl commands have not accepted names for ports, only numbers, and have not been able to display port names either. It's a lot easier for users if they can use and see meaningful names instead of arbitrary numbers. This commit adds that support. For backward compatibility, only interactive ovs-ofctl commands by default display port names; to display them in scripts, use the new --names option. Signed-off-by: Ben Pfaff <blp@ovn.org> Tested-by: Aaron Conole <aconole@redhat.com>
* userspace: Add packet_type in dp_packet and flowJan Scheurich2017-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix format specifier technicalities.Ben Pfaff2017-03-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Various printf() format specifiers in the tree had minor technical issues which the Mac OS build reported, e.g. here: https://s3.amazonaws.com/archive.travis-ci.org/jobs/208718342/log.txt These tend to fall into two categories of harmless warnings: 1. Wrong width for types that are all promoted to 'int'. For example, both uint8_t and uint16_t are both promoted to 'int' as part of a call to printf(), but using PRIu8 for a uint16_t causes a warning. 2. Wrong format specifier for type promoted to 'int' due to arithmetic. For example, if 'x' is a uint8_t, then x >> 1 has type 'int' due to C's promotion rules, so the correct format specifier is %d and using PRIu8 will cause a warning. This commit fixes the warnings. I didn't see anything that rose to the level of a bug. These warnings only showed up on Mac OS X because of differences in the format specifiers that Mac OS uses for PRI*. Reported-by: Shu Shen <shu.shen@gmail.com> Acked-by: Daniele Di Proietto <diproiettod@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Add support for 802.1ad (QinQ tunneling)Eric Garver2017-03-161-28/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flow key handling changes: - Add VLAN header array in struct flow, to record multiple 802.1q VLAN headers. - Add dpif multi-VLAN capability probing. If datapath supports multi-VLAN, increase the maximum depth of nested OVS_KEY_ATTR_ENCAP. Refactor VLAN handling in dpif-xlate: - Introduce 'xvlan' to track VLAN stack during flow processing. - Input and output VLAN translation according to the xbundle type. Push VLAN action support: - Allow ethertype 0x88a8 in VLAN headers and push_vlan action. - Support push_vlan on dot1q packets. Use other_config:vlan-limit in table Open_vSwitch to limit maximum VLANs that can be matched. This allows us to preserve backwards compatibility. Add test cases for VLAN depth limit, Multi-VLAN actions and QinQ VLAN handling Co-authored-by: Thomas F Herbert <thomasfherbert@gmail.com> Signed-off-by: Thomas F Herbert <thomasfherbert@gmail.com> Co-authored-by: Xiao Liang <shaw.leon@gmail.com> Signed-off-by: Xiao Liang <shaw.leon@gmail.com> Signed-off-by: Eric Garver <e@erig.me> Signed-off-by: Ben Pfaff <blp@ovn.org>
* odp: Support conntrack orig tuple key.Jarno Rajahalme2017-03-081-1/+109
| | | | | | Userspace support for datapath original direction conntrack tuple. Signed-off-by: Jarno Rajahalme <jarno@ovn.org> Acked-by: Joe Stringer <joe@ovn.org>
* flow: Make room after ct_state.Jarno Rajahalme2017-03-081-4/+4
| | | | | | | 'ct_state' currently only needs 8 bits, so we can make room for a new CT field introduced in the next patch. Signed-off-by: Jarno Rajahalme <jarno@ovn.org> Acked-by: Joe Stringer <joe@ovn.org>
* tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis.Jesse Gross2016-09-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* match: Only print external tunnel flags.Jesse Gross2016-08-191-2/+2
| | | | | | | | | Some tunnel flags are purely internal implementation details (primarily FLOW_TNL_F_UDPIF). These shouldn't be output when we format tunnel flows, so this masks them out. Signed-off-by: Jesse Gross <jesse@kernel.org> Acked-by: Ben Pfaff <blp@ovn.org>
* Introduce 128-bit xxregs.Justin Pettit2016-07-121-0/+15
| | | | | | | These are needed to handle IPv6 addresses. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* Increase number of registers to 16.Justin Pettit2016-07-121-1/+1
| | | | | | | | With eight 32-bit registers, we can only store two IPv6 addresses, which is pretty tight. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* util: Pass 128-bit arguments directly instead of using pointers.Justin Pettit2016-05-081-2/+2
| | | | | | | | | | | Commit f2d105b5 (ofproto-dpif-xlate: xlate ct_{mark, label} correctly.) introduced the ovs_u128_and() function. It directly takes ovs_u128 values as arguments instead of pointers to them. As this is a bit more direct way to deal with 128-bit values, modify the other utility functions to do the same. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Joe Stringer <joe@ovn.org>
* Move lib/ofp-util.h to include/openvswitch directoryBen Warren2016-04-141-1/+1
| | | | | | | | This commit also adds several #include directives in source files in order to make the 'ofp-util.h' move possible Signed-off-by: Ben Warren <ben@skyportsystems.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Move lib/match.h to include/openvswitch directoryBen Warren2016-04-141-1/+2
| | | | | Signed-off-by: Ben Warren <ben@skyportsystems.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* Move lib/dynamic-string.h to include/openvswitch directoryBen Warren2016-03-191-1/+1
| | | | | Signed-off-by: Ben Warren <ben@skyportsystems.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* match: Color output of match conditions for ovs-ofctl dump-flows.Quentin Monnet2016-03-181-55/+71
| | | | | | | | | Add color output for flow match conditions for ovs-ofctl dump-flows command utility, by inserting color markers in the functions responsible for printing those match condictions. Signed-off-by: Quentin Monnet <quentin.monnet@6wind.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* openflow: Support matching and modifying MPLS TTL field.Ben Pfaff2016-03-071-1/+18
| | | | | | | | Occasionally we get asked about this and I don't see a reason not to support it. Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org>
* tunneling: extend flow_tnl with ipv6 addressesJiri Benc2015-11-301-1/+35
| | | | | | | | | | | | | | | | Note that because there's been no prerequisite on the outer protocol, we cannot add it now. Instead, treat the ipv4 and ipv6 dst fields in the way that either both are null, or at most one of them is non-null. [cascardo: abstract testing either dst with flow_tnl_dst_is_set] cascardo: using IPv4-mapped address is an exercise for the future, since this would require special handling of MFF_TUN_SRC and MFF_TUN_DST and OpenFlow messages. Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Co-authored-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* byte-order: Make hton128() and ntoh128() behave like their counterparts.Justin Pettit2015-11-241-4/+2
| | | | | | | | Instead of taking the source and destination as arguments, make these functions act like their short and long counterparts. Signed-off-by: Justin Pettit <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* packets: Change IPv6 functions to more closely resemble IPv4 ones.Justin Pettit2015-11-241-1/+1
| | | | | Signed-off-by: Justin Petitt <jpettit@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org>
* Add connection tracking label support.Joe Stringer2015-10-131-0/+40
| | | | | | | | | | | | | | | | | | | | | | This patch adds a new 128-bit metadata field to the connection tracking interface. When a label is specified as part of the ct action and the connection is committed, the value is saved with the current connection. Subsequent ct lookups with the table specified will expose this metadata as the "ct_label" field in the flow. For example, to allow new TCP connections from port 1->2 and only allow established connections from port 2->1, and to associate a label with those connections: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,action=ct(commit,exec(set_field:1->ct_label)),2 table=0,in_port=2,ct_state=-trk,tcp,action=ct(table=1) table=1,in_port=2,ct_state=+trk,ct_label=1,tcp,action=1 Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* Add connection tracking mark support.Joe Stringer2015-10-131-0/+18
| | | | | | | | | | | | | | | | | | | | | | This patch adds a new 32-bit metadata field to the connection tracking interface. When a mark is specified as part of the ct action and the connection is committed, the value is saved with the current connection. Subsequent ct lookups with the table specified will expose this metadata as the "ct_mark" field in the flow. For example, to allow new TCP connections from port 1->2 and only allow established connections from port 2->1, and to associate a mark with those connections: table=0,priority=1,action=drop table=0,arp,action=normal table=0,in_port=1,tcp,action=ct(commit,exec(set_field:1->ct_mark)),2 table=0,in_port=2,ct_state=-trk,tcp,action=ct(table=1) table=1,in_port=2,ct_state=+trk,ct_mark=1,tcp,action=1 Signed-off-by: Joe Stringer <joestringer@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* Add support for connection tracking.Joe Stringer2015-10-131-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* userspace: Define and use struct eth_addr.Jarno Rajahalme2015-08-281-37/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Define struct eth_addr and use it instead of a uint8_t array for all ethernet addresses in OVS userspace. The struct is always the right size, and it can be assigned without an explicit memcpy, which makes code more readable. "struct eth_addr" is a good type name for this as many utility functions are already named accordingly. struct eth_addr can be accessed as bytes as well as ovs_be16's, which makes the struct 16-bit aligned. All use seems to be 16-bit aligned, so some algorithms on the ethernet addresses can be made a bit more efficient making use of this fact. As the struct fits into a register (in 64-bit systems) we pass it by value when possible. This patch also changes the few uses of Linux specific ETH_ALEN to OVS's own ETH_ADDR_LEN, and removes the OFP_ETH_ALEN, as it is no longer needed. This work stemmed from a desire to make all struct flow members assignable for unrelated exploration purposes. However, I think this might be a nice code readability improvement by itself. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
* flow: Add struct flowmap.Jarno Rajahalme2015-08-261-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Struct miniflow is now sometimes used just as a map. Define a new struct flowmap for that purpose. The flowmap is defined as an array of maps, and it is automatically sized according to the size of struct flow, so it will be easier to maintain in the future. It would have been tempting to use the existing struct bitmap for this purpose. The main reason this is not feasible at the moment is that some flowmap algorithms are simpler when it can be assumed that no struct flow member requires more bits than can fit to a single map unit. The tunnel member already requires more than 32 bits, so the map unit needs to be 64 bits wide. Performance critical algorithms enumerate the flowmap array units explicitly, as it is easier for the compiler to optimize, compared to the normal iterator. Without this optimization a classifier lookup without wildcard masks would be about 25% slower. With this more general (and maintainable) algorithm the classifier lookups are about 5% slower, when the struct flow actually becomes big enough to require a second map. This negates the performance gained in the "Pre-compute stage masks" patch earlier in the series. Requested-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* flow: Split miniflow's map.Jarno Rajahalme2015-07-171-2/+2
| | | | | | | | | | | | | | | | | Use two maps in miniflow to allow for expansion of struct flow past 512 bytes. We now have one map for tunnel related fields, and another for the rest of the packet metadata and actual packet header fields. This split has the benefit that for non-tunneled packets the overhead should be minimal. Some miniflow utilities now exist in two variants, new ones operating over all the data, and the old ones operating only on a single 64-bit map at a time. The old ones require doubling of code but should execute faster, so those are used in the datapath and classifier's lookup path. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* flow: Make compile with MSVC.Jarno Rajahalme2015-07-161-4/+6
| | | | | | | | | MSVC does not like zero sized arrays in structs. Hence, remove the 'values' member from struct miniflow and add back the getters miniflow_values() and miniflow_get_values(). Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* tunneling: Allow matching and setting tunnel 'OAM' flag.Jesse Gross2015-07-151-2/+7
| | | | | | | | | | | | | | | | | Several encapsulation formats have the concept of an 'OAM' bit which typically is used with networking tracing tools to distinguish test packets from real traffic. OVS already internally has support for this, however, it doesn't do anything with it and it also isn't exposed for controllers to use. This enables support through OpenFlow. There are several other tunnel flags which are consumed internally by OVS. It's not clear that it makes sense to use them externally so this does not expose those flags - although it should be easy to do so if necessary in the future. Signed-off-by: Jesse Gross <jesse@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* flow: Factor out flag parsing and formatting routines.Jesse Gross2015-07-151-14/+3
| | | | | | | | | There are several implementations of functions that parse/format flags and their binary representation. This factors them out into common routines. In addition to reducing code, it also makes things more consistent across different parts of OVS. Signed-off-by: Jesse Gross <jesse@nicira.com>
* match: Single malloc minimatch.Jarno Rajahalme2015-07-151-5/+12
| | | | | | | | | | | | | | | | Allocate the miniflow and minimask in struct minimatch at once, so that they are consecutive in memory. This halves the number of allocations, and allows smaller minimatches to share the same cache line. After this a minimatch has one heap allocation for all it's data. Previously it had either none (when data was small enough to fit in struct miniflow's inline buffer), or two (when the inline buffer was insufficient). Hopefully always having one performs almost the same as none or two, in average. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* flow: Always inline miniflows.Jarno Rajahalme2015-07-151-15/+15
| | | | | | | | | | | Now that performance critical code already inlines miniflows and minimasks, we can simplify struct miniflow by always dynamically allocating miniflows and minimasks to the correct size. This changes the struct minimatch to always contain pointers to its miniflow and minimask. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* tunnel: Geneve TLV handling support for OpenFlow.Jesse Gross2015-06-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* match: Do not skip formatting a zero dp_hash.Jarno Rajahalme2015-03-161-1/+1
| | | | | | | | | | The dp_hash match should be printed whenever it is being matched. We keep the old behavior for flow_format(), which is mostly used to format PACKET_IN messages. This keeps those messages tidier and avoids changing a lot of test cases. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Andy Zhou <azhou@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* ofproto: Add NXM_NX_TUN_GBP_ID and NXM_NX_TUN_GBP_FLAGSMadhu Challa2015-02-141-1/+36
| | | | | | | | | | | | | | | | | | | Introduces two new NXMs to represent VXLAN-GBP [0] fields. actions=load:0x10->NXM_NX_TUN_GBP_ID[],NORMAL tun_gbp_id=0x10,actions=drop This enables existing VXLAN tunnels to carry security label information such as a SELinux context to other network peers. The values are carried to/from the datapath using the attribute OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS. [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy-00 Signed-off-by: Madhu Challa <challa@noironetworks.com> Acked-by: Ben Pfaff <blp@nicira.com> Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
* classifier: Add support for conjunctive matches.Ben Pfaff2015-01-111-2/+13
| | | | | | | | | | A "conjunctive match" allows higher-level matches in the flow table, such as set membership matches, without causing a cross-product explosion for multidimensional matches. Please refer to the documentation that this commit adds to ovs-ofctl(8) for a better explanation, including an example. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
* miniflow: Use 64-bit data.Jarno Rajahalme2015-01-061-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far the compressed flow data in struct miniflow has been in 32-bit words with a 63-bit map, allowing for a maximum size of struct flow of 252 bytes. With the forthcoming Geneve options this is not sufficient any more. This patch solves the problem by changing the miniflow data to 64-bit words, doubling the flow max size to 504 bytes. Since the word size is doubled, there is some loss in compression efficiency. To counter this some of the flow fields have been reordered to keep related fields together (e.g., the source and destination IP addresses share the same 64-bit word). This change should speed up flow data processing on 64-bit CPUs, which may help counterbalance the impact of making the struct flow bigger in the future. Classifier lookup stage boundaries are also changed to 64-bit alignment, as the current algorithm depends on each miniflow word to not be split between ranges. This has resulted in new padding (part of the 'mpls_lse' field). The 'dp_hash' field is also moved to packet metadata to eliminate otherwise needed padding there. This allows the L4 to fit into one 64-bit word, and also makes matches on 'dp_hash' more efficient as misses can be found already on stage 1. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* lib: Use MAP_FOR_EACH_INDEX to improve readability.Jarno Rajahalme2014-11-261-3/+3
| | | | | | | Use MAP_FOR_EACH_INDEX to improve readability when there is no apparent cost for it. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* match: Use ds_chomp() in match_format()Simon Horman2014-11-041-2/+2
| | | | | | | | Slightly simplify match_format() by using ds_chomp() rather than open-coding its logic. Signed-off-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* flow: Support OF1.5+ (draft) actset_output field.Ben Pfaff2014-11-031-1/+14
| | | | | | | | | This field allows a flow table to match on the output port currently in the action set. ONF-JIRA: EXT-233 Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
* classifier: Change type used for priorities from 'unsigned int' to 'int'.Ben Pfaff2014-10-301-6/+5
| | | | | | | | | | | | | | | | OpenFlow has priorities in the 16-bit unsigned range, from 0 to 65535. In the classifier, it is sometimes useful to be able to have values below and above this range. With the 'unsigned int' type used for priorities until now, there were no values below the range, so some code worked around it by converting priorities to 64-bit signed integers. This didn't seem so great to me given that a plain 'int' also had the needed range. This commit therefore changes the type used for priorities to int. The interesting parts of this change are in pvector.h and classifier.c, where one can see the elimination of the use of int64_t. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
* Use magic ETH_ADDR_LEN instead of 6 for Ethernet address length.Wang Sheng-Hui2014-10-221-2/+3
| | | | | | | | | ETH_ADDR_LEN is defined in lib/packets.h, valued 6. Use this macro instead of magic number 6 to represent the length of eth mac address. Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* lib/match: Do not format undefined fields.Jarno Rajahalme2014-10-061-104/+7
| | | | | | | | | | | | | | Add function flow_wildcards_init_for_packet() that can be used to set sensible wildcards when megaflows are disabled. Before this, we set all the mask bits to ones, which caused printing tunnel, mpls, and/or transport port fields even for packets for which it makes no sense. This has the side effect of generating different megaflow masks for different packet types, so there will be more than one kind of mask in the datapath classifier. This should not make practical difference, as megaflows should not be disabled when performance is important. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* lib: Unify flags parsing and formatting.Jarno Rajahalme2014-09-081-2/+9
| | | | | | | | | | | | | | Use the "+-" syntax more uniformly when printing masked flags, and use the syntax of delimited 1-flags also for formatting fully masked TCP flags. The "+-" syntax only deals with masked flags, but if there are many of those, the printout becomes long and confusing. Typically there are many flags only when flags are fully masked, but even then most of them are zeros, so it makes sense to print the flags that are set (ones) and omit the zero flags. Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com> Acked-by: Ben Pfaff <blp@nicira.com>
* meta-flow: Add 64-bit registers.Ben Pfaff2014-07-281-0/+15
| | | | | | | | | These 64-bit registers are intended to conform with the OpenFlow 1.5 draft specification. EXT-244. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
* flow: extend it to carry IGMP protocol informationFlavio Leitner2014-06-241-1/+7
| | | | | | | Add IGMP info to struct flow, flow compose and flow extract. Signed-off-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
View Lorry Controller Status