mir/ovs
2
0
Fork 0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00
Code Issues Releases Wiki Activity
ovs/lib/dpif.h

159 lines
5.4 KiB
C
Raw Normal View History

Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
/*
dpif: Update dpif interface to match netdev. This brings over some features that were added to the netdev interface, most notably the separation between the name and the type. In addition to being cleaner, this also avoids problems where it is expected that the local port has the same name as the datapath.
2010-01-22 14:37:10 -05:00
* Copyright (c) 2008, 2009, 2010 Nicira Networks.
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
*
Update primary code license to Apache 2.0.
2009-06-15 15:11:30 -07:00
* 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:
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
*
Update primary code license to Apache 2.0.
2009-06-15 15:11:30 -07:00
* 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.
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
*/
#ifndef DPIF_H
#define DPIF_H 1
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
ofproto: Avoid user->kernel->user round-trip for many controller actions. When an OpenFlow flow says to send packets to the controller, until now ofproto has executed that using dpif_execute(), which passes the packet up to the kernel. The kernel queues the packet into its "action" queue, and then later ofproto pulls the packet back down from the kernel and sends it to the controller. However, this is unnecessary. Open vSwitch can just recognize in advance that it will get the packet back and handle it directly, skipping the round trip. This commit implements this optimization. This generally affects only the first packet in a flow, since generally the rest come directly down from the kernel. It only optimizes the "easy" case where the first action in a flow is to send the packet to the controller, since this seems to be the common case in the flows that I'm looking at now.
2010-08-04 14:08:26 -07:00
#include "openflow/openflow.h"
#include "openvswitch/datapath-protocol.h"
#include "util.h"
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
Add extern "C" to more header files. From partner.
2010-02-17 10:36:57 -05:00
#ifdef __cplusplus
extern "C" {
#endif
dpif: Hide the contents of struct dpif. This helps prepare for multiple dpif implementations, and ensures that code outside dpif.c does not depend on its internals.
2009-06-16 10:09:10 -07:00
struct dpif;
datapath: Make adding and attaching a vport a single step. For some time now, Open vSwitch datapaths have internally made a distinction between adding a vport and attaching it to a datapath. Adding a vport just means to create it, as an entity detached from any datapath. Attaching it gives it a port number and a datapath. Similarly, a vport could be detached and deleted separately. After some study, I think I understand why this distinction exists. It is because ovs-vswitchd tries to open all the datapath ports before it tries to create them. However, changing it to create them before it tries to open them is not difficult, so this commit does this. The bulk of this commit, however, changes the datapath interface to one that always creates a vport and attaches it to a datapath in a single step, and similarly detaches a vport and deletes it in a single step. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2010-12-03 14:41:38 -08:00
struct netdev;
datapath: Replace "struct odp_action" by Netlink attributes. In the medium term, we plan to migrate the datapath to use Netlink as its communication channel. In the short term, we need to be able to have actions with 64-bit arguments but "struct odp_action" only has room for 48 bits. So this patch shifts to variable-length arguments using Netlink attributes, which starts in on the Netlink transition and makes 64-bit arguments possible at the same time. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2010-12-10 10:40:58 -08:00
struct nlattr;
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
struct ofpbuf;
vswitch: Avoid knowledge of details specific to Linux datapaths. At startup, the vswitch needs to delete datapaths that are not configured by the administrator. Until now this was done by knowing the possible names of Linux datapaths. This commit cleans up by allowing each datapath class to enumerate its existing datapaths and their names.
2009-07-06 11:06:36 -07:00
struct svec;
dpif: Allow providers to be managed at runtime. The list of datapath providers was previously staticly defined at compile time. This allows new providers to be added and removed at runtime.
2010-02-01 11:36:01 -05:00
struct dpif_class;
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
dpif: Add new functions dp_run() and dp_wait(). The upcoming netdev-based dpif needs a hook where it can process packets and throw them against the flow table, and this provides a suitable place.
2009-06-19 14:09:09 -07:00
void dp_run(void);
void dp_wait(void);
dpif: Allow providers to be managed at runtime. The list of datapath providers was previously staticly defined at compile time. This allows new providers to be added and removed at runtime.
2010-02-01 11:36:01 -05:00
int dp_register_provider(const struct dpif_class *);
int dp_unregister_provider(const char *type);
dpif: Update dpif interface to match netdev. This brings over some features that were added to the netdev interface, most notably the separation between the name and the type. In addition to being cleaner, this also avoids problems where it is expected that the local port has the same name as the datapath.
2010-01-22 14:37:10 -05:00
void dp_enumerate_types(struct svec *types);
dpif: Allow providers to be managed at runtime. The list of datapath providers was previously staticly defined at compile time. This allows new providers to be added and removed at runtime.
2010-02-01 11:36:01 -05:00
dpif: Update dpif interface to match netdev. This brings over some features that were added to the netdev interface, most notably the separation between the name and the type. In addition to being cleaner, this also avoids problems where it is expected that the local port has the same name as the datapath.
2010-01-22 14:37:10 -05:00
int dp_enumerate_names(const char *type, struct svec *names);
void dp_parse_name(const char *datapath_name, char **name, char **type);
dpif: Add new functions dp_run() and dp_wait(). The upcoming netdev-based dpif needs a hook where it can process packets and throw them against the flow table, and this provides a suitable place.
2009-06-19 14:09:09 -07:00
dpif: Update dpif interface to match netdev. This brings over some features that were added to the netdev interface, most notably the separation between the name and the type. In addition to being cleaner, this also avoids problems where it is expected that the local port has the same name as the datapath.
2010-01-22 14:37:10 -05:00
int dpif_open(const char *name, const char *type, struct dpif **);
int dpif_create(const char *name, const char *type, struct dpif **);
int dpif_create_and_open(const char *name, const char *type, struct dpif **);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
void dpif_close(struct dpif *);
dpif: Replace dpif_id() by dpif_name(). dpif_id() is often used in error messages, e.g. "dp%u: screwed up". But soon we will be generalizing the concept of a datapath, so it is better to have a function that returns a full name, e.g. "%s: screwed up". Accordingly, this commit replaces dpif_id() by a new function dpif_name() that does so.
2009-06-16 11:00:22 -07:00
const char *dpif_name(const struct dpif *);
dpif: Update dpif interface to match netdev. This brings over some features that were added to the netdev interface, most notably the separation between the name and the type. In addition to being cleaner, this also avoids problems where it is expected that the local port has the same name as the datapath.
2010-01-22 14:37:10 -05:00
const char *dpif_base_name(const struct dpif *);
vswitch: Avoid knowledge of details specific to Linux datapaths. At startup, the vswitch needs to delete datapaths that are not configured by the administrator. Until now this was done by knowing the possible names of Linux datapaths. This commit cleans up by allowing each datapath class to enumerate its existing datapaths and their names.
2009-07-06 11:06:36 -07:00
int dpif_get_all_names(const struct dpif *, struct svec *);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
int dpif_delete(struct dpif *);
int dpif_get_dp_stats(const struct dpif *, struct odp_stats *);
int dpif_get_drop_frags(const struct dpif *, bool *drop_frags);
int dpif_set_drop_frags(struct dpif *, bool drop_frags);
datapath: Make adding and attaching a vport a single step. For some time now, Open vSwitch datapaths have internally made a distinction between adding a vport and attaching it to a datapath. Adding a vport just means to create it, as an entity detached from any datapath. Attaching it gives it a port number and a datapath. Similarly, a vport could be detached and deleted separately. After some study, I think I understand why this distinction exists. It is because ovs-vswitchd tries to open all the datapath ports before it tries to create them. However, changing it to create them before it tries to open them is not difficult, so this commit does this. The bulk of this commit, however, changes the datapath interface to one that always creates a vport and attaches it to a datapath in a single step, and similarly detaches a vport and deletes it in a single step. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2010-12-03 14:41:38 -08:00
int dpif_port_add(struct dpif *, struct netdev *, uint16_t *port_nop);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
int dpif_port_del(struct dpif *, uint16_t port_no);
int dpif_port_query_by_number(const struct dpif *, uint16_t port_no,
struct odp_port *);
int dpif_port_query_by_name(const struct dpif *, const char *devname,
struct odp_port *);
dpif: Rename dpif_get_name() to dpif_port_get_name(), update interface. With multiple kinds of datapaths, code should not just use "dp%u" along with dpif_minor() to print a datapath name, because not all datapaths can sensibly be named that way. We want to use a function with a name like dpif_get_name() to retrieve a datapath name for printing to the user, in which case the existing dpif_get_name() function would be confusing. So rename the existing one to something more explicit.
2009-06-15 16:51:46 -07:00
int dpif_port_get_name(struct dpif *, uint16_t port_no,
char *name, size_t name_size);
datapath: Change listing ports to use an iterator concept. One of the goals for Open vSwitch is to decouple kernel and userspace software, so that either one can be upgraded or rolled back independent of the other. To do this in full generality, it must be possible to add new features to the kernel vport layer without changing userspace software. In turn, that means that the odp_port structure must become variable-length. This does not, however, fit in well with the ODP_PORT_LIST ioctl in its current form, because that would require userspace to know how much space to allocate for each port in advance, or to allocate as much space as could possibly be needed. Neither choice is very attractive. This commit prepares for a different solution, by replacing ODP_PORT_LIST by a new ioctl ODP_VPORT_DUMP that retrieves information about a single vport from the datapath on each call. It is much cleaner to allocate the maximum amount of space for a single vport than to do so for possibly a large number of vports. It would be faster to retrieve a number of vports in batch instead of just one at a time, but that will naturally happen later when the kernel datapath interface is changed to use Netlink, so this patch does not bother with it. The Netlink version won't need to take the starting port number from userspace, since Netlink sockets can keep track of that state as part of their "dump" feature. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-10 13:12:12 -08:00
struct dpif_port_dump {
const struct dpif *dpif;
int error;
void *state;
};
void dpif_port_dump_start(struct dpif_port_dump *, const struct dpif *);
bool dpif_port_dump_next(struct dpif_port_dump *, struct odp_port *);
int dpif_port_dump_done(struct dpif_port_dump *);
/* Iterates through each ODP_PORT in DPIF, using DUMP as state.
*
* Arguments all have pointer type.
*
* If you break out of the loop, then you need to free the dump structure by
* hand using dpif_port_dump_done(). */
#define DPIF_PORT_FOR_EACH(ODP_PORT, DUMP, DPIF) \
for (dpif_port_dump_start(DUMP, DPIF); \
(dpif_port_dump_next(DUMP, ODP_PORT) \
? true \
: (dpif_port_dump_done(DUMP), false)); \
)
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
Introduce general-purpose ways to wait for dpif and netdev changes. The dpif and netdev code has had various ways to check for changes to dpifs and netdevs over the course of Open vSwitch development. All of these have been thus far fairly specific to the Linux implementation. This commit is the start of a more general API for watching for such changes. The dpif-related parts seem fairly mature and so they are documented, the netdev parts will probably need to change somewhat and so they are not documented yet.
2009-06-24 10:24:09 -07:00
int dpif_port_poll(const struct dpif *, char **devnamep);
void dpif_port_poll_wait(const struct dpif *);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
int dpif_flow_flush(struct dpif *);
int dpif_flow_put(struct dpif *, struct odp_flow_put *);
int dpif_flow_del(struct dpif *, struct odp_flow *);
int dpif_flow_get(const struct dpif *, struct odp_flow *);
int dpif_flow_get_multiple(const struct dpif *, struct odp_flow[], size_t n);
datapath: Change listing flows to use an iterator concept. One of the goals for Open vSwitch is to decouple kernel and userspace software, so that either one can be upgraded or rolled back independent of the other. To do this in full generality, it must be possible to change the kernel's idea of the flow key separately from the userspace version. In turn, that means that flow keys must become variable-length. This does not, however, fit in well with the ODP_FLOW_LIST ioctl in its current form, because that would require userspace to know how much space to allocate for each flow's key in advance, or to allocate as much space as could possibly be needed. Neither choice is very attractive. This commit prepares for a different solution, by replacing ODP_FLOW_LIST by a new ioctl ODP_FLOW_DUMP that retrieves a single flow from the datapath on each call. It is much cleaner to allocate the maximum amount of space for a single flow key than to do so for possibly a very large number of flow keys. As a side effect, this patch also fixes a race condition that sometimes made "ovs-dpctl dump-flows" print an error: previously, flows were listed and then their actions were retrieved, which left a window in which ovs-vswitchd could delete the flow. Now dumping a flow and its actions is a single step, closing that window. Dumping all of the flows in a datapath is no longer an atomic step, so now it is possible to miss some flows or see a single flow twice during iteration, if the flow table is modified by another process. It doesn't look like this should be a problem for ovs-vswitchd. It would be faster to retrieve a number of flows in batch instead of just one at a time, but that will naturally happen later when the kernel datapath interface is changed to use Netlink, so this patch does not bother with it. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2010-12-28 10:39:52 -08:00
struct dpif_flow_dump {
const struct dpif *dpif;
int error;
void *state;
};
void dpif_flow_dump_start(struct dpif_flow_dump *, const struct dpif *);
bool dpif_flow_dump_next(struct dpif_flow_dump *, struct odp_flow *);
int dpif_flow_dump_done(struct dpif_flow_dump *);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
datapath: Replace "struct odp_action" by Netlink attributes. In the medium term, we plan to migrate the datapath to use Netlink as its communication channel. In the short term, we need to be able to have actions with 64-bit arguments but "struct odp_action" only has room for 48 bits. So this patch shifts to variable-length arguments using Netlink attributes, which starts in on the Netlink transition and makes 64-bit arguments possible at the same time. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2010-12-10 10:40:58 -08:00
int dpif_execute(struct dpif *, const struct nlattr *actions,
size_t actions_len, const struct ofpbuf *);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
datapath: Report kernel's flow key when passing packets up to userspace. One of the goals for Open vSwitch is to decouple kernel and userspace software, so that either one can be upgraded or rolled back independent of the other. To do this in full generality, it must be possible to change the kernel's idea of the flow key separately from the userspace version. This commit takes one step in that direction by making the kernel report its idea of the flow that a packet belongs to whenever it passes a packet up to userspace. This means that userspace can intelligently figure out what to do: - If userspace's notion of the flow for the packet matches the kernel's, then nothing special is necessary. - If the kernel has a more specific notion for the flow than userspace, for example if the kernel decoded IPv6 headers but userspace stopped at the Ethernet type (because it does not understand IPv6), then again nothing special is necessary: userspace can still set up the flow in the usual way. - If userspace has a more specific notion for the flow than the kernel, for example if userspace decoded an IPv6 header but the kernel stopped at the Ethernet type, then userspace can forward the packet manually, without setting up a flow in the kernel. (This case is bad from a performance point of view, but at least it is correct.) This commit does not actually make userspace flexible enough to handle changes in the kernel flow key structure, although userspace does now have enough information to do that intelligently. This will have to wait for later commits. This commit is bigger than it would otherwise be because it is rolled together with changing "struct odp_msg" to a sequence of Netlink attributes. The alternative, to do each of those changes in a separate patch, seemed like overkill because it meant that either we would have to introduce and then kill off Netlink attributes for in_port and tun_id, if Netlink conversion went first, or shove yet another variable-length header into the stuff already after odp_msg, if adding the flow key to odp_msg went first. This commit will slow down performance of checksumming packets sent up to userspace. I'm not entirely pleased with how I did it. I considered a couple of alternatives, but none of them seemed that much better. Suggestions welcome. Not changing anything wasn't an option, unfortunately. At any rate some slowdown will become unavoidable when OVS actually starts using Netlink instead of just Netlink framing. (Actually, I thought of one option where we could avoid that: make userspace do the checksum instead, by passing csum_start and csum_offset as part of what goes to userspace. But that's not perfect either.) Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-24 14:59:57 -08:00
/* A packet passed up from the datapath to userspace.
*
* If 'key' or 'actions' is nonnull, then it points into data owned by
* 'packet', so their memory cannot be freed separately. (This is hardly a
* great way to do things but it works out OK for the dpif providers and
* clients that exist so far.)
*/
struct dpif_upcall {
uint32_t type; /* One of _ODPL_*_NR. */
/* All types. */
struct ofpbuf *packet; /* Packet data. */
struct nlattr *key; /* Flow key. */
size_t key_len; /* Length of 'key' in bytes. */
/* _ODPL_ACTION_NR only. */
uint64_t userdata; /* Argument to ODPAT_CONTROLLER. */
/* _ODPL_SFLOW_NR only. */
uint32_t sample_pool; /* # of sampling candidate packets so far. */
struct nlattr *actions; /* Associated flow actions. */
size_t actions_len;
};
ofproto: Avoid user->kernel->user round-trip for many controller actions. When an OpenFlow flow says to send packets to the controller, until now ofproto has executed that using dpif_execute(), which passes the packet up to the kernel. The kernel queues the packet into its "action" queue, and then later ofproto pulls the packet back down from the kernel and sends it to the controller. However, this is unnecessary. Open vSwitch can just recognize in advance that it will get the packet back and handle it directly, skipping the round trip. This commit implements this optimization. This generally affects only the first packet in a flow, since generally the rest come directly down from the kernel. It only optimizes the "easy" case where the first action in a flow is to send the packet to the controller, since this seems to be the common case in the flows that I'm looking at now.
2010-08-04 14:08:26 -07:00
dpif: Rename odp_msg related functions for more consistency. This seems like a more consistent naming scheme, since all of these functions are related but none of them were named similarly or grouped together.
2009-06-17 14:18:10 -07:00
int dpif_recv_get_mask(const struct dpif *, int *listen_mask);
int dpif_recv_set_mask(struct dpif *, int listen_mask);
Initial implementation of sFlow. Tested very slightly with "ping" and "sflowtool -t | tcpdump -r -".
2010-01-04 13:08:37 -08:00
int dpif_get_sflow_probability(const struct dpif *, uint32_t *probability);
int dpif_set_sflow_probability(struct dpif *, uint32_t probability);
datapath: Report kernel's flow key when passing packets up to userspace. One of the goals for Open vSwitch is to decouple kernel and userspace software, so that either one can be upgraded or rolled back independent of the other. To do this in full generality, it must be possible to change the kernel's idea of the flow key separately from the userspace version. This commit takes one step in that direction by making the kernel report its idea of the flow that a packet belongs to whenever it passes a packet up to userspace. This means that userspace can intelligently figure out what to do: - If userspace's notion of the flow for the packet matches the kernel's, then nothing special is necessary. - If the kernel has a more specific notion for the flow than userspace, for example if the kernel decoded IPv6 headers but userspace stopped at the Ethernet type (because it does not understand IPv6), then again nothing special is necessary: userspace can still set up the flow in the usual way. - If userspace has a more specific notion for the flow than the kernel, for example if userspace decoded an IPv6 header but the kernel stopped at the Ethernet type, then userspace can forward the packet manually, without setting up a flow in the kernel. (This case is bad from a performance point of view, but at least it is correct.) This commit does not actually make userspace flexible enough to handle changes in the kernel flow key structure, although userspace does now have enough information to do that intelligently. This will have to wait for later commits. This commit is bigger than it would otherwise be because it is rolled together with changing "struct odp_msg" to a sequence of Netlink attributes. The alternative, to do each of those changes in a separate patch, seemed like overkill because it meant that either we would have to introduce and then kill off Netlink attributes for in_port and tun_id, if Netlink conversion went first, or shove yet another variable-length header into the stuff already after odp_msg, if adding the flow key to odp_msg went first. This commit will slow down performance of checksumming packets sent up to userspace. I'm not entirely pleased with how I did it. I considered a couple of alternatives, but none of them seemed that much better. Suggestions welcome. Not changing anything wasn't an option, unfortunately. At any rate some slowdown will become unavoidable when OVS actually starts using Netlink instead of just Netlink framing. (Actually, I thought of one option where we could avoid that: make userspace do the checksum instead, by passing csum_start and csum_offset as part of what goes to userspace. But that's not perfect either.) Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-24 14:59:57 -08:00
int dpif_recv(struct dpif *, struct dpif_upcall *);
dpif: Rename odp_msg related functions for more consistency. This seems like a more consistent naming scheme, since all of these functions are related but none of them were named similarly or grouped together.
2009-06-17 14:18:10 -07:00
int dpif_recv_purge(struct dpif *);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
void dpif_recv_wait(struct dpif *);
dpif: New function dpif_get_netflow_ids(). The 'minor' member of struct dpif is used for two different purposes: for printing in log messages and for encapsulating in NetFlow messages. The needs in each case are different, so we should break up these uses. This commit does half of that, by introducing a new function to retrieve NetFlow ids and using it where appropriate.
2009-06-16 10:59:43 -07:00
void dpif_get_netflow_ids(const struct dpif *,
uint8_t *engine_type, uint8_t *engine_id);
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
dpif: Abstract translation from OpenFlow queue ID into ODP priority value. When the QoS code was integrated, I didn't yet know how to abstract the translation from a queue ID in an OpenFlow OFPAT_ENQUEUE action into a priority value for an ODP ODPAT_SET_PRIORITY action. This commit is a first attempt that works OK for Linux, so far. It's possible that in fact this translation needs the 'netdev' as an argument too, but it's not needed yet.
2010-07-20 11:23:21 -07:00
int dpif_queue_to_priority(const struct dpif *, uint32_t queue_id,
uint32_t *priority);
Add extern "C" to more header files. From partner.
2010-02-17 10:36:57 -05:00
#ifdef __cplusplus
}
#endif
Import from old repository commit 61ef2b42a9c4ba8e1600f15bb0236765edc2ad45.
2009-07-08 13:19:16 -07:00
#endif /* dpif.h */
Reference in New Issue Copy Permalink