2 * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
4 * Licensed under the Apache License, Version 2.0 (the "License");
5 * you may not use this file except in compliance with the License.
6 * You may obtain a copy of the License at:
8 * http://www.apache.org/licenses/LICENSE-2.0
10 * Unless required by applicable law or agreed to in writing, software
11 * distributed under the License is distributed on an "AS IS" BASIS,
12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13 * See the License for the specific language governing permissions and
14 * limitations under the License.
18 * dpif, the DataPath InterFace.
20 * In Open vSwitch terminology, a "datapath" is a flow-based software switch.
21 * A datapath has no intelligence of its own. Rather, it relies entirely on
22 * its client to set up flows. The datapath layer is core to the Open vSwitch
23 * software switch: one could say, without much exaggeration, that everything
24 * in ovs-vswitchd above dpif exists only to make the correct decisions
25 * interacting with dpif.
27 * Typically, the client of a datapath is the software switch module in
28 * "ovs-vswitchd", but other clients can be written. The "ovs-dpctl" utility
29 * is also a (simple) client.
35 * The terms written in quotes below are defined in later sections.
37 * When a datapath "port" receives a packet, it extracts the headers (the
38 * "flow"). If the datapath's "flow table" contains a "flow entry" matching
39 * the packet, then it executes the "actions" in the flow entry and increments
40 * the flow's statistics. If there is no matching flow entry, the datapath
41 * instead appends the packet to an "upcall" queue.
47 * A datapath has a set of ports that are analogous to the ports on an Ethernet
48 * switch. At the datapath level, each port has the following information
51 * - A name, a short string that must be unique within the host. This is
52 * typically a name that would be familiar to the system administrator,
53 * e.g. "eth0" or "vif1.1", but it is otherwise arbitrary.
55 * - A 32-bit port number that must be unique within the datapath but is
56 * otherwise arbitrary. The port number is the most important identifier
57 * for a port in the datapath interface.
59 * - A type, a short string that identifies the kind of port. On a Linux
60 * host, typical types are "system" (for a network device such as eth0),
61 * "internal" (for a simulated port used to connect to the TCP/IP stack),
62 * and "gre" (for a GRE tunnel).
64 * - A Netlink PID for each upcall reading thread (see "Upcall Queuing and
67 * The dpif interface has functions for adding and deleting ports. When a
68 * datapath implements these (e.g. as the Linux and netdev datapaths do), then
69 * Open vSwitch's ovs-vswitchd daemon can directly control what ports are used
70 * for switching. Some datapaths might not implement them, or implement them
71 * with restrictions on the types of ports that can be added or removed
72 * (e.g. on ESX), on systems where port membership can only be changed by some
75 * Each datapath must have a port, sometimes called the "local port", whose
76 * name is the same as the datapath itself, with port number 0. The local port
79 * Ports are available as "struct netdev"s. To obtain a "struct netdev *" for
80 * a port named 'name' with type 'port_type', in a datapath of type
81 * 'datapath_type', call netdev_open(name, dpif_port_open_type(datapath_type,
82 * port_type). The netdev can be used to get and set important data related to
85 * - MTU (netdev_get_mtu(), netdev_set_mtu()).
87 * - Ethernet address (netdev_get_etheraddr(), netdev_set_etheraddr()).
89 * - Statistics such as the number of packets and bytes transmitted and
90 * received (netdev_get_stats()).
92 * - Carrier status (netdev_get_carrier()).
94 * - Speed (netdev_get_features()).
96 * - QoS queue configuration (netdev_get_queue(), netdev_set_queue() and
99 * - Arbitrary port-specific configuration parameters (netdev_get_config(),
100 * netdev_set_config()). An example of such a parameter is the IP
101 * endpoint for a GRE tunnel.
107 * The flow table is a collection of "flow entries". Each flow entry contains:
109 * - A "flow", that is, a summary of the headers in an Ethernet packet. The
110 * flow must be unique within the flow table. Flows are fine-grained
111 * entities that include L2, L3, and L4 headers. A single TCP connection
112 * consists of two flows, one in each direction.
114 * In Open vSwitch userspace, "struct flow" is the typical way to describe
115 * a flow, but the datapath interface uses a different data format to
116 * allow ABI forward- and backward-compatibility. datapath/README
117 * describes the rationale and design. Refer to OVS_KEY_ATTR_* and
118 * "struct ovs_key_*" in include/odp-netlink.h for details.
119 * lib/odp-util.h defines several functions for working with these flows.
121 * - A "mask" that, for each bit in the flow, specifies whether the datapath
122 * should consider the corresponding flow bit when deciding whether a
123 * given packet matches the flow entry. The original datapath design did
124 * not support matching: every flow entry was exact match. With the
125 * addition of a mask, the interface supports datapaths with a spectrum of
126 * wildcard matching capabilities, from those that only support exact
127 * matches to those that support bitwise wildcarding on the entire flow
128 * key, as well as datapaths with capabilities somewhere in between.
130 * Datapaths do not provide a way to query their wildcarding capabilities,
131 * nor is it expected that the client should attempt to probe for the
132 * details of their support. Instead, a client installs flows with masks
133 * that wildcard as many bits as acceptable. The datapath then actually
134 * wildcards as many of those bits as it can and changes the wildcard bits
135 * that it does not support into exact match bits. A datapath that can
136 * wildcard any bit, for example, would install the supplied mask, an
137 * exact-match only datapath would install an exact-match mask regardless
138 * of what mask the client supplied, and a datapath in the middle of the
139 * spectrum would selectively change some wildcard bits into exact match
142 * Regardless of the requested or installed mask, the datapath retains the
143 * original flow supplied by the client. (It does not, for example, "zero
144 * out" the wildcarded bits.) This allows the client to unambiguously
145 * identify the flow entry in later flow table operations.
147 * The flow table does not have priorities; that is, all flow entries have
148 * equal priority. Detecting overlapping flow entries is expensive in
149 * general, so the datapath is not required to do it. It is primarily the
150 * client's responsibility not to install flow entries whose flow and mask
151 * combinations overlap.
153 * - A list of "actions" that tell the datapath what to do with packets
154 * within a flow. Some examples of actions are OVS_ACTION_ATTR_OUTPUT,
155 * which transmits the packet out a port, and OVS_ACTION_ATTR_SET, which
156 * modifies packet headers. Refer to OVS_ACTION_ATTR_* and "struct
157 * ovs_action_*" in include/odp-netlink.h for details. lib/odp-util.h
158 * defines several functions for working with datapath actions.
160 * The actions list may be empty. This indicates that nothing should be
161 * done to matching packets, that is, they should be dropped.
163 * (In case you are familiar with OpenFlow, datapath actions are analogous
164 * to OpenFlow actions.)
166 * - Statistics: the number of packets and bytes that the flow has
167 * processed, the last time that the flow processed a packet, and the
168 * union of all the TCP flags in packets processed by the flow. (The
169 * latter is 0 if the flow is not a TCP flow.)
171 * The datapath's client manages the flow table, primarily in reaction to
172 * "upcalls" (see below).
178 * A datapath sometimes needs to notify its client that a packet was received.
179 * The datapath mechanism to do this is called an "upcall".
181 * Upcalls are used in two situations:
183 * - When a packet is received, but there is no matching flow entry in its
184 * flow table (a flow table "miss"), this causes an upcall of type
185 * DPIF_UC_MISS. These are called "miss" upcalls.
187 * - A datapath action of type OVS_ACTION_ATTR_USERSPACE causes an upcall of
188 * type DPIF_UC_ACTION. These are called "action" upcalls.
190 * An upcall contains an entire packet. There is no attempt to, e.g., copy
191 * only as much of the packet as normally needed to make a forwarding decision.
192 * Such an optimization is doable, but experimental prototypes showed it to be
193 * of little benefit because an upcall typically contains the first packet of a
194 * flow, which is usually short (e.g. a TCP SYN). Also, the entire packet can
195 * sometimes really be needed.
197 * After a client reads a given upcall, the datapath is finished with it, that
198 * is, the datapath doesn't maintain any lingering state past that point.
200 * The latency from the time that a packet arrives at a port to the time that
201 * it is received from dpif_recv() is critical in some benchmarks. For
202 * example, if this latency is 1 ms, then a netperf TCP_CRR test, which opens
203 * and closes TCP connections one at a time as quickly as it can, cannot
204 * possibly achieve more than 500 transactions per second, since every
205 * connection consists of two flows with 1-ms latency to set up each one.
207 * To receive upcalls, a client has to enable them with dpif_recv_set(). A
208 * datapath should generally support being opened multiple times (e.g. so that
209 * one may run "ovs-dpctl show" or "ovs-dpctl dump-flows" while "ovs-vswitchd"
210 * is also running) but need not support more than one of these clients
211 * enabling upcalls at once.
214 * Upcall Queuing and Ordering
215 * ---------------------------
217 * The datapath's client reads upcalls one at a time by calling dpif_recv().
218 * When more than one upcall is pending, the order in which the datapath
219 * presents upcalls to its client is important. The datapath's client does not
220 * directly control this order, so the datapath implementer must take care
223 * The minimal behavior, suitable for initial testing of a datapath
224 * implementation, is that all upcalls are appended to a single queue, which is
225 * delivered to the client in order.
227 * The datapath should ensure that a high rate of upcalls from one particular
228 * port cannot cause upcalls from other sources to be dropped or unreasonably
229 * delayed. Otherwise, one port conducting a port scan or otherwise initiating
230 * high-rate traffic spanning many flows could suppress other traffic.
231 * Ideally, the datapath should present upcalls from each port in a "round
232 * robin" manner, to ensure fairness.
234 * The client has no control over "miss" upcalls and no insight into the
235 * datapath's implementation, so the datapath is entirely responsible for
236 * queuing and delivering them. On the other hand, the datapath has
237 * considerable freedom of implementation. One good approach is to maintain a
238 * separate queue for each port, to prevent any given port's upcalls from
239 * interfering with other ports' upcalls. If this is impractical, then another
240 * reasonable choice is to maintain some fixed number of queues and assign each
241 * port to one of them. Ports assigned to the same queue can then interfere
242 * with each other, but not with ports assigned to different queues. Other
243 * approaches are also possible.
245 * The client has some control over "action" upcalls: it can specify a 32-bit
246 * "Netlink PID" as part of the action. This terminology comes from the Linux
247 * datapath implementation, which uses a protocol called Netlink in which a PID
248 * designates a particular socket and the upcall data is delivered to the
249 * socket's receive queue. Generically, though, a Netlink PID identifies a
250 * queue for upcalls. The basic requirements on the datapath are:
252 * - The datapath must provide a Netlink PID associated with each port. The
253 * client can retrieve the PID with dpif_port_get_pid().
255 * - The datapath must provide a "special" Netlink PID not associated with
256 * any port. dpif_port_get_pid() also provides this PID. (ovs-vswitchd
257 * uses this PID to queue special packets that must not be lost even if a
258 * port is otherwise busy, such as packets used for tunnel monitoring.)
260 * The minimal behavior of dpif_port_get_pid() and the treatment of the Netlink
261 * PID in "action" upcalls is that dpif_port_get_pid() returns a constant value
262 * and all upcalls are appended to a single queue.
264 * The preferred behavior is:
266 * - Each port has a PID that identifies the queue used for "miss" upcalls
267 * on that port. (Thus, if each port has its own queue for "miss"
268 * upcalls, then each port has a different Netlink PID.)
270 * - "miss" upcalls for a given port and "action" upcalls that specify that
271 * port's Netlink PID add their upcalls to the same queue. The upcalls
272 * are delivered to the datapath's client in the order that the packets
273 * were received, regardless of whether the upcalls are "miss" or "action"
276 * - Upcalls that specify the "special" Netlink PID are queued separately.
278 * Multiple threads may want to read upcalls simultaneously from a single
279 * datapath. To support multiple threads well, one extends the above preferred
282 * - Each port has multiple PIDs. The datapath distributes "miss" upcalls
283 * across the PIDs, ensuring that a given flow is mapped in a stable way
286 * - For "action" upcalls, the thread can specify its own Netlink PID or
287 * other threads' Netlink PID of the same port for offloading purpose
288 * (e.g. in a "round robin" manner).
294 * The datapath interface works with packets in a particular form. This is the
295 * form taken by packets received via upcalls (i.e. by dpif_recv()). Packets
296 * supplied to the datapath for processing (i.e. to dpif_execute()) also take
299 * A VLAN tag is represented by an 802.1Q header. If the layer below the
300 * datapath interface uses another representation, then the datapath interface
301 * must perform conversion.
303 * The datapath interface requires all packets to fit within the MTU. Some
304 * operating systems internally process packets larger than MTU, with features
305 * such as TSO and UFO. When such a packet passes through the datapath
306 * interface, it must be broken into multiple MTU or smaller sized packets for
307 * presentation as upcalls. (This does not happen often, because an upcall
308 * typically contains the first packet of a flow, which is usually short.)
310 * Some operating system TCP/IP stacks maintain packets in an unchecksummed or
311 * partially checksummed state until transmission. The datapath interface
312 * requires all host-generated packets to be fully checksummed (e.g. IP and TCP
313 * checksums must be correct). On such an OS, the datapath interface must fill
314 * in these checksums.
316 * Packets passed through the datapath interface must be at least 14 bytes
317 * long, that is, they must have a complete Ethernet header. They are not
318 * required to be padded to the minimum Ethernet length.
324 * Typically, the client of a datapath begins by configuring the datapath with
325 * a set of ports. Afterward, the client runs in a loop polling for upcalls to
328 * For each upcall received, the client examines the enclosed packet and
329 * figures out what should be done with it. For example, if the client
330 * implements a MAC-learning switch, then it searches the forwarding database
331 * for the packet's destination MAC and VLAN and determines the set of ports to
332 * which it should be sent. In any case, the client composes a set of datapath
333 * actions to properly dispatch the packet and then directs the datapath to
334 * execute those actions on the packet (e.g. with dpif_execute()).
336 * Most of the time, the actions that the client executed on the packet apply
337 * to every packet with the same flow. For example, the flow includes both
338 * destination MAC and VLAN ID (and much more), so this is true for the
339 * MAC-learning switch example above. In such a case, the client can also
340 * direct the datapath to treat any further packets in the flow in the same
341 * way, using dpif_flow_put() to add a new flow entry.
343 * Other tasks the client might need to perform, in addition to reacting to
346 * - Periodically polling flow statistics, perhaps to supply to its own
349 * - Deleting flow entries from the datapath that haven't been used
350 * recently, to save memory.
352 * - Updating flow entries whose actions should change. For example, if a
353 * MAC learning switch learns that a MAC has moved, then it must update
354 * the actions of flow entries that sent packets to the MAC at its old
357 * - Adding and removing ports to achieve a new configuration.
363 * Most of the dpif functions are fully thread-safe: they may be called from
364 * any number of threads on the same or different dpif objects. The exceptions
367 * - dpif_port_poll() and dpif_port_poll_wait() are conditionally
368 * thread-safe: they may be called from different threads only on
369 * different dpif objects.
371 * - dpif_flow_dump_next() is conditionally thread-safe: It may be called
372 * from different threads with the same 'struct dpif_flow_dump', but all
373 * other parameters must be different for each thread.
375 * - dpif_flow_dump_done() is conditionally thread-safe: All threads that
376 * share the same 'struct dpif_flow_dump' must have finished using it.
377 * This function must then be called exactly once for a particular
378 * dpif_flow_dump to finish the corresponding flow dump operation.
380 * - Functions that operate on 'struct dpif_port_dump' are conditionally
381 * thread-safe with respect to those objects. That is, one may dump ports
382 * from any number of threads at once, but each thread must use its own
383 * struct dpif_port_dump.
393 #include "openflow/openflow.h"
409 int dp_register_provider(const struct dpif_class *);
410 int dp_unregister_provider(const char *type);
411 void dp_blacklist_provider(const char *type);
412 void dp_enumerate_types(struct sset *types);
413 const char *dpif_normalize_type(const char *);
415 int dp_enumerate_names(const char *type, struct sset *names);
416 void dp_parse_name(const char *datapath_name, char **name, char **type);
418 int dpif_open(const char *name, const char *type, struct dpif **);
419 int dpif_create(const char *name, const char *type, struct dpif **);
420 int dpif_create_and_open(const char *name, const char *type, struct dpif **);
421 void dpif_close(struct dpif *);
423 void dpif_run(struct dpif *);
424 void dpif_wait(struct dpif *);
426 const char *dpif_name(const struct dpif *);
427 const char *dpif_base_name(const struct dpif *);
428 const char *dpif_type(const struct dpif *);
430 int dpif_delete(struct dpif *);
432 /* Statistics for a dpif as a whole. */
433 struct dpif_dp_stats {
434 uint64_t n_hit; /* Number of flow table matches. */
435 uint64_t n_missed; /* Number of flow table misses. */
436 uint64_t n_lost; /* Number of misses not sent to userspace. */
437 uint64_t n_flows; /* Number of flows present. */
438 uint64_t n_mask_hit; /* Number of mega flow masks visited for
439 flow table matches. */
440 uint32_t n_masks; /* Number of mega flow masks. */
442 int dpif_get_dp_stats(const struct dpif *, struct dpif_dp_stats *);
445 /* Port operations. */
447 const char *dpif_port_open_type(const char *datapath_type,
448 const char *port_type);
449 int dpif_port_add(struct dpif *, struct netdev *, odp_port_t *port_nop);
450 int dpif_port_del(struct dpif *, odp_port_t port_no);
452 /* A port within a datapath.
454 * 'name' and 'type' are suitable for passing to netdev_open(). */
456 char *name; /* Network device name, e.g. "eth0". */
457 char *type; /* Network device type, e.g. "system". */
458 odp_port_t port_no; /* Port number within datapath. */
460 void dpif_port_clone(struct dpif_port *, const struct dpif_port *);
461 void dpif_port_destroy(struct dpif_port *);
462 bool dpif_port_exists(const struct dpif *dpif, const char *devname);
463 int dpif_port_query_by_number(const struct dpif *, odp_port_t port_no,
465 int dpif_port_query_by_name(const struct dpif *, const char *devname,
467 int dpif_port_get_name(struct dpif *, odp_port_t port_no,
468 char *name, size_t name_size);
469 uint32_t dpif_port_get_pid(const struct dpif *, odp_port_t port_no,
472 struct dpif_port_dump {
473 const struct dpif *dpif;
477 void dpif_port_dump_start(struct dpif_port_dump *, const struct dpif *);
478 bool dpif_port_dump_next(struct dpif_port_dump *, struct dpif_port *);
479 int dpif_port_dump_done(struct dpif_port_dump *);
481 /* Iterates through each DPIF_PORT in DPIF, using DUMP as state.
483 * Arguments all have pointer type.
485 * If you break out of the loop, then you need to free the dump structure by
486 * hand using dpif_port_dump_done(). */
487 #define DPIF_PORT_FOR_EACH(DPIF_PORT, DUMP, DPIF) \
488 for (dpif_port_dump_start(DUMP, DPIF); \
489 (dpif_port_dump_next(DUMP, DPIF_PORT) \
491 : (dpif_port_dump_done(DUMP), false)); \
494 int dpif_port_poll(const struct dpif *, char **devnamep);
495 void dpif_port_poll_wait(const struct dpif *);
497 /* Flow table operations. */
499 struct dpif_flow_stats {
506 void dpif_flow_stats_extract(const struct flow *, const struct ofpbuf *packet,
507 long long int used, struct dpif_flow_stats *);
508 void dpif_flow_stats_format(const struct dpif_flow_stats *, struct ds *);
510 enum dpif_flow_put_flags {
511 DPIF_FP_CREATE = 1 << 0, /* Allow creating a new flow. */
512 DPIF_FP_MODIFY = 1 << 1, /* Allow modifying an existing flow. */
513 DPIF_FP_ZERO_STATS = 1 << 2 /* Zero the stats of an existing flow. */
516 int dpif_flow_flush(struct dpif *);
517 int dpif_flow_put(struct dpif *, enum dpif_flow_put_flags,
518 const struct nlattr *key, size_t key_len,
519 const struct nlattr *mask, size_t mask_len,
520 const struct nlattr *actions, size_t actions_len,
521 struct dpif_flow_stats *);
522 int dpif_flow_del(struct dpif *,
523 const struct nlattr *key, size_t key_len,
524 struct dpif_flow_stats *);
525 int dpif_flow_get(const struct dpif *,
526 const struct nlattr *key, size_t key_len,
527 struct ofpbuf **, struct dpif_flow *);
529 /* Flow dumping interface
530 * ======================
532 * This interface allows iteration through all of the flows currently installed
533 * in a datapath. It is somewhat complicated by two requirements:
535 * - Efficient support for dumping flows in parallel from multiple threads.
537 * - Allow callers to avoid making unnecessary copies of data returned by
538 * the interface across several flows in cases where the dpif
539 * implementation has to maintain a copy of that information anyhow.
540 * (That is, allow the client visibility into any underlying batching as
541 * part of its own batching.)
547 * 1. Call dpif_flow_dump_create().
548 * 2. In each thread that participates in the dump (which may be just a single
549 * thread if parallelism isn't important):
550 * (a) Call dpif_flow_dump_thread_create().
551 * (b) Call dpif_flow_dump_next() repeatedly until it returns 0.
552 * (c) Call dpif_flow_dump_thread_destroy().
553 * 3. Call dpif_flow_dump_destroy().
555 * All error reporting is deferred to the call to dpif_flow_dump_destroy().
557 struct dpif_flow_dump *dpif_flow_dump_create(const struct dpif *);
558 int dpif_flow_dump_destroy(struct dpif_flow_dump *);
560 struct dpif_flow_dump_thread *dpif_flow_dump_thread_create(
561 struct dpif_flow_dump *);
562 void dpif_flow_dump_thread_destroy(struct dpif_flow_dump_thread *);
564 /* A datapath flow as dumped by dpif_flow_dump_next(). */
566 const struct nlattr *key; /* Flow key, as OVS_KEY_ATTR_* attrs. */
567 size_t key_len; /* 'key' length in bytes. */
568 const struct nlattr *mask; /* Flow mask, as OVS_KEY_ATTR_* attrs. */
569 size_t mask_len; /* 'mask' length in bytes. */
570 const struct nlattr *actions; /* Actions, as OVS_ACTION_ATTR_ */
571 size_t actions_len; /* 'actions' length in bytes. */
572 struct dpif_flow_stats stats; /* Flow statistics. */
574 int dpif_flow_dump_next(struct dpif_flow_dump_thread *,
575 struct dpif_flow *flows, int max_flows);
577 /* Operation batching interface.
579 * Some datapaths are faster at performing N operations together than the same
580 * N operations individually, hence an interface for batching.
584 DPIF_OP_FLOW_PUT = 1,
589 struct dpif_flow_put {
591 enum dpif_flow_put_flags flags; /* DPIF_FP_*. */
592 const struct nlattr *key; /* Flow to put. */
593 size_t key_len; /* Length of 'key' in bytes. */
594 const struct nlattr *mask; /* Mask to put. */
595 size_t mask_len; /* Length of 'mask' in bytes. */
596 const struct nlattr *actions; /* Actions to perform on flow. */
597 size_t actions_len; /* Length of 'actions' in bytes. */
600 struct dpif_flow_stats *stats; /* Optional flow statistics. */
603 struct dpif_flow_del {
605 const struct nlattr *key; /* Flow to delete. */
606 size_t key_len; /* Length of 'key' in bytes. */
609 struct dpif_flow_stats *stats; /* Optional flow statistics. */
612 struct dpif_execute {
613 /* Raw support for execute passed along to the provider. */
614 const struct nlattr *actions; /* Actions to execute on packet. */
615 size_t actions_len; /* Length of 'actions' in bytes. */
616 struct ofpbuf *packet; /* Packet to execute. */
617 struct pkt_metadata md; /* Packet metadata. */
619 /* Some dpif providers do not implement every action. The Linux kernel
620 * datapath, in particular, does not implement ARP field modification.
622 * If this member is set to true, the dpif layer executes in userspace all
623 * of the actions that it can, and for OVS_ACTION_ATTR_OUTPUT and
624 * OVS_ACTION_ATTR_USERSPACE actions it passes the packet through to the
625 * dpif implementation. */
629 int dpif_execute(struct dpif *, struct dpif_execute *);
632 enum dpif_op_type type;
635 struct dpif_flow_put flow_put;
636 struct dpif_flow_del flow_del;
637 struct dpif_execute execute;
641 void dpif_operate(struct dpif *, struct dpif_op **ops, size_t n_ops);
645 enum dpif_upcall_type {
646 DPIF_UC_MISS, /* Miss in flow table. */
647 DPIF_UC_ACTION, /* OVS_ACTION_ATTR_USERSPACE action. */
651 const char *dpif_upcall_type_to_string(enum dpif_upcall_type);
653 /* A packet passed up from the datapath to userspace.
655 * The 'packet', 'key' and 'userdata' may point into data in a buffer
656 * provided by the caller, so the buffer should be released only after the
657 * upcall processing has been finished.
659 * While being processed, the 'packet' may be reallocated, so the packet must
660 * be separately released with ofpbuf_uninit().
664 enum dpif_upcall_type type;
665 struct ofpbuf packet; /* Packet data. */
666 struct nlattr *key; /* Flow key. */
667 size_t key_len; /* Length of 'key' in bytes. */
669 /* DPIF_UC_ACTION only. */
670 struct nlattr *userdata; /* Argument to OVS_ACTION_ATTR_USERSPACE. */
673 typedef void exec_upcall_cb(struct dpif *, struct dpif_upcall *,
674 struct ofpbuf *, int cnt);
676 int dpif_recv_set(struct dpif *, bool enable);
677 int dpif_handlers_set(struct dpif *, uint32_t n_handlers);
678 int dpif_recv(struct dpif *, uint32_t handler_id, struct dpif_upcall *,
680 void dpif_recv_purge(struct dpif *);
681 void dpif_recv_wait(struct dpif *, uint32_t handler_id);
682 void dpif_register_upcall_cb(struct dpif *, exec_upcall_cb *);
683 void dpif_enable_upcall(struct dpif *);
684 void dpif_disable_upcall(struct dpif *);
686 void dpif_print_packet(struct dpif *, struct dpif_upcall *);
690 void dpif_get_netflow_ids(const struct dpif *,
691 uint8_t *engine_type, uint8_t *engine_id);
693 int dpif_queue_to_priority(const struct dpif *, uint32_t queue_id,