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-provider.h

375 lines
17 KiB
C
Raw Normal View History

dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/*
datapath: Drop queue information from odp_stats. This queue information will be available through the kernel socket layer once we move over to Netlink socket as transports, so we might as well get rid of the redundancy. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-04 17:00:36 -08:00
* Copyright (c) 2009, 2010, 2011 Nicira Networks.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef DPIF_PROVIDER_H
#define DPIF_PROVIDER_H 1
/* Provider interface to dpifs, which provide an interface to an Open vSwitch
Add guide to porting Open vSwitch.
2010-06-07 14:05:56 -07:00
* datapath. A datapath is a collection of physical or virtual ports that are
* exposed over OpenFlow as a single switch. Datapaths and the collections of
* ports that they contain may be fixed or dynamic. */
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
#include <assert.h>
ofproto: Avoid buffer copy in OFPT_PACKET_IN path. When a dpif passes an odp_msg down to ofproto, and ofproto transforms it into an ofp_packet_in to send to the controller, until now this always involved a full copy of the packet inside ofproto. This commit eliminates this copy by ensuring that there is always enough headroom in the ofpbuf that holds the odp_msg to replace it by an ofp_packet_in in-place. From Jean Tourrilhes <jt@hpl.hp.com>, with some revisions.
2010-04-27 09:40:46 -07:00
#include "openflow/openflow.h"
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
#include "dpif.h"
ofproto: Avoid buffer copy in OFPT_PACKET_IN path. When a dpif passes an odp_msg down to ofproto, and ofproto transforms it into an ofp_packet_in to send to the controller, until now this always involved a full copy of the packet inside ofproto. This commit eliminates this copy by ensuring that there is always enough headroom in the ofpbuf that holds the odp_msg to replace it by an ofp_packet_in in-place. From Jean Tourrilhes <jt@hpl.hp.com>, with some revisions.
2010-04-27 09:40:46 -07:00
#include "util.h"
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
#ifdef __cplusplus
extern "C" {
#endif
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Open vSwitch datapath interface.
*
* This structure should be treated as opaque by dpif implementations. */
struct dpif {
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
const struct dpif_class *dpif_class;
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
char *base_name;
char *full_name;
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
uint8_t netflow_engine_type;
uint8_t netflow_engine_id;
};
void dpif_init(struct dpif *, const struct dpif_class *, const char *name,
uint8_t netflow_engine_type, uint8_t netflow_engine_id);
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
void dpif_uninit(struct dpif *dpif, bool close);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
static inline void dpif_assert_class(const struct dpif *dpif,
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
const struct dpif_class *dpif_class)
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
{
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
assert(dpif->dpif_class == dpif_class);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
}
/* Datapath interface class structure, to be defined by each implementation of
dpif: Minor provider comment cleanups.
2009-11-30 23:20:57 -08:00
* a datapath interface.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*
* These functions return 0 if successful or a positive errno value on failure,
* except where otherwise noted.
*
* These functions are expected to execute synchronously, that is, to block as
* necessary to obtain a result. Thus, they may not return EAGAIN or
* EWOULDBLOCK or EINPROGRESS. We may relax this requirement in the future if
* and when we encounter performance problems. */
struct dpif_class {
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
/* Type of dpif in this class, e.g. "system", "netdev", etc.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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
* One of the providers should supply a "system" type, since this is
* the type assumed if no type is specified when opening a dpif. */
const char *type;
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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
/* Performs periodic work needed by dpifs of this class, if any is
* necessary. */
void (*run)(void);
/* Arranges for poll_block() to wake up if the "run" member function needs
* to be called. */
void (*wait)(void);
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
/* Enumerates the names of all known created datapaths, if possible, into
* 'all_dps'. The caller has already initialized 'all_dps' and other dpif
* classes might already have added names to it.
*
* This is used by the vswitch at startup, so that it can delete any
* datapaths that are not configured.
*
* Some kinds of datapaths might not be practically enumerable, in which
* case this function may be a null pointer. */
int (*enumerate)(struct svec *all_dps);
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
/* Attempts to open an existing dpif called 'name', if 'create' is false,
* or to open an existing dpif or create a new one, if 'create' is true.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*
dpif: Make dpif_class 'open' function take class instead of type name. This makes it easier for dpif_provider implementations to share code but distinguish the class actually in use, because comparing a pointer is easier than comparing a string.
2010-11-18 10:06:41 -08:00
* 'dpif_class' is the class of dpif to open.
*
* If successful, stores a pointer to the new dpif in '*dpifp', which must
* have class 'dpif_class'. On failure there are no requirements on what
* is stored in '*dpifp'. */
int (*open)(const struct dpif_class *dpif_class,
const char *name, bool create, struct dpif **dpifp);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Closes 'dpif' and frees associated memory. */
void (*close)(struct dpif *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
/* Enumerates all names that may be used to open 'dpif' into 'all_names'.
* The Linux datapath, for example, supports opening a datapath both by
* number, e.g. "dp0", and by the name of the datapath's local port. For
* some datapaths, this might be an infinite set (e.g. in a file name,
* slashes may be duplicated any number of times), in which case only the
* names most likely to be used should be enumerated.
*
* The caller has already initialized 'all_names' and might already have
* added some names to it. This function should not disturb any existing
* names in 'all_names'.
*
* If a datapath class does not support multiple names for a datapath, this
* function may be a null pointer.
*
* This is used by the vswitch at startup, */
int (*get_all_names)(const struct dpif *dpif, struct svec *all_names);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Attempts to destroy the dpif underlying 'dpif'.
*
* If successful, 'dpif' will not be used again except as an argument for
* the 'close' member function. */
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
int (*destroy)(struct dpif *dpif);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Retrieves statistics for 'dpif' into 'stats'. */
int (*get_stats)(const struct dpif *dpif, struct odp_stats *stats);
/* Retrieves 'dpif''s current treatment of IP fragments into '*drop_frags':
* true indicates that fragments are dropped, false indicates that
* fragments are treated in the same way as other IP packets (except that
* the L4 header cannot be read). */
int (*get_drop_frags)(const struct dpif *dpif, bool *drop_frags);
/* Changes 'dpif''s treatment of IP fragments to 'drop_frags', whose
* meaning is the same as for the get_drop_frags member function. */
int (*set_drop_frags)(struct dpif *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
/* Adds 'netdev' as a new port in 'dpif'. If successful, sets '*port_no'
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
* to the new port's port number. */
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 (*port_add)(struct dpif *dpif, struct netdev *netdev,
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
uint16_t *port_no);
/* Removes port numbered 'port_no' from 'dpif'. */
int (*port_del)(struct dpif *dpif, uint16_t port_no);
/* Queries 'dpif' for a port with the given 'port_no' or 'devname'. Stores
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
* information about the port into '*port' if successful.
*
* The caller takes ownership of data in 'port' and must free it with
* dpif_port_destroy() when it is no longer needed. */
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
int (*port_query_by_number)(const struct dpif *dpif, uint16_t port_no,
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
struct dpif_port *port);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
int (*port_query_by_name)(const struct dpif *dpif, const char *devname,
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
struct dpif_port *port);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
datapath: Drop port information from odp_stats. As with n_flows, n_ports was used regularly by userspace to determine how much memory to allocate when listing ports, but it is no longer needed for that. max_ports, on the other hand, is necessary but it is also a fixed value for the kernel datapath right now and if we expand it we can also come up with a way to report the expanded value. The remaining members of odp_stats are actually real statistics that I intend to keep. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-26 09:24:59 -08:00
/* Returns one greater than the largest port number accepted in flow
* actions. */
int (*get_max_ports)(const struct dpif *dpif);
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
/* Attempts to begin dumping the ports in a dpif. On success, returns 0
* and initializes '*statep' with any data needed for iteration. On
* failure, returns a positive errno value. */
int (*port_dump_start)(const struct dpif *dpif, void **statep);
/* Attempts to retrieve another port from 'dpif' for 'state', which was
* initialized by a successful call to the 'port_dump_start' function for
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
* 'dpif'. On success, stores a new dpif_port into 'port' and returns 0.
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
* Returns EOF if the end of the port table has been reached, or a positive
* errno value on error. This function will not be called again once it
* returns nonzero once for a given iteration (but the 'port_dump_done'
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
* function will be called afterward).
*
* The dpif provider retains ownership of the data stored in 'port'. It
* must remain valid until at least the next call to 'port_dump_next' or
* 'port_dump_done' for 'state'. */
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
int (*port_dump_next)(const struct dpif *dpif, void *state,
dpif: Eliminate "struct odp_port" from client-visible interface. Following this commit, "struct odp_port" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-23 18:48:02 -08:00
struct dpif_port *port);
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
/* Releases resources from 'dpif' for 'state', which was initialized by a
* successful call to the 'port_dump_start' function for 'dpif'. */
int (*port_dump_done)(const struct dpif *dpif, void *state);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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
/* Polls for changes in the set of ports in 'dpif'. If the set of ports in
* 'dpif' has changed, then this function should do one of the
* following:
*
* - Preferably: store the name of the device that was added to or deleted
* from 'dpif' in '*devnamep' and return 0. The caller is responsible
* for freeing '*devnamep' (with free()) when it no longer needs it.
*
* - Alternatively: return ENOBUFS, without indicating the device that was
* added or deleted.
*
* Occasional 'false positives', in which the function returns 0 while
* indicating a device that was not actually added or deleted or returns
* ENOBUFS without any change, are acceptable.
*
* If the set of ports in 'dpif' has not changed, returns EAGAIN. May also
* return other positive errno values to indicate that something has gone
* wrong. */
int (*port_poll)(const struct dpif *dpif, char **devnamep);
/* Arranges for the poll loop to wake up when 'port_poll' will return a
* value other than EAGAIN. */
void (*port_poll_wait)(const struct dpif *dpif);
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
/* Queries 'dpif' for a flow entry. The flow is specified by the Netlink
* attributes with types ODP_KEY_ATTR_* in the 'key_len' bytes starting at
* 'key'.
datapath: Change ODP_FLOW_GET to retrieve only a single flow at a time. This brings the code closer to what the Netlink interface will need to implement. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-17 14:40:58 -08:00
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* Returns 0 if successful. If no flow matches, returns ENOENT. On other
* failure, returns a positive errno value.
datapath: Change ODP_FLOW_GET to retrieve only a single flow at a time. This brings the code closer to what the Netlink interface will need to implement. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-17 14:40:58 -08:00
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* If 'actionsp' is nonnull, then on success '*actionsp' must be set to an
* ofpbuf owned by the caller that contains the Netlink attributes for the
* flow's actions. The caller must free the ofpbuf (with ofpbuf_delete())
* when it is no longer needed.
*
* If 'stats' is nonnull, then on success it must be updated with the
* flow's statistics. */
int (*flow_get)(const struct dpif *dpif, int flags,
const struct nlattr *key, size_t key_len,
dpif: Eliminate "struct odp_flow_stats" from client-visible interface. Following this commit, "struct odp_flow_stats" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:11:50 -08:00
struct ofpbuf **actionsp, struct dpif_flow_stats *stats);
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
/* Adds or modifies a flow in 'dpif'. The flow is specified by the Netlink
* attributes with types ODP_KEY_ATTR_* in the 'key_len' bytes starting at
* 'key'. The associated actions are specified by the Netlink attributes
* with types ODPAT_* in the 'actions_len' bytes starting at 'actions'.
*
* - If the flow's key does not exist in 'dpif', then the flow will be
* added if 'flags' includes ODPPF_CREATE. Otherwise the operation will
* fail with ENOENT.
*
* If the operation succeeds, then 'stats', if nonnull, must be zeroed.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* - If the flow's key does exist in 'dpif', then the flow's actions will
* be updated if 'flags' includes ODPPF_MODIFY. Otherwise the operation
* will fail with EEXIST. If the flow's actions are updated, then its
* statistics will be zeroed if 'flags' includes ODPPF_ZERO_STATS, and
* left as-is otherwise.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* If the operation succeeds, then 'stats', if nonnull, must be set to
* the flow's statistics before the update.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*/
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
int (*flow_put)(struct dpif *dpif, int flags,
const struct nlattr *key, size_t key_len,
const struct nlattr *actions, size_t actions_len,
dpif: Eliminate "struct odp_flow_stats" from client-visible interface. Following this commit, "struct odp_flow_stats" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:11:50 -08:00
struct dpif_flow_stats *stats);
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
/* Deletes a flow from 'dpif' and returns 0, or returns ENOENT if 'dpif'
* does not contain such a flow. The flow is specified by the Netlink
* attributes with types ODP_KEY_ATTR_* in the 'key_len' bytes starting at
* 'key'.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* If the operation succeeds, then 'stats', if nonnull, must be set to the
* flow's statistics before its deletion. */
int (*flow_del)(struct dpif *dpif,
const struct nlattr *key, size_t key_len,
dpif: Eliminate "struct odp_flow_stats" from client-visible interface. Following this commit, "struct odp_flow_stats" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:11:50 -08:00
struct dpif_flow_stats *stats);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Deletes all flows from 'dpif' and clears all of its queues of received
* packets. */
int (*flow_flush)(struct dpif *dpif);
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
/* Attempts to begin dumping the flows in a dpif. On success, returns 0
* and initializes '*statep' with any data needed for iteration. On
* failure, returns a positive errno value. */
int (*flow_dump_start)(const struct dpif *dpif, void **statep);
/* Attempts to retrieve another flow from 'dpif' for 'state', which was
* initialized by a successful call to the 'flow_dump_start' function for
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* 'dpif'. On success, updates the output parameters as described below
* and returns 0. Returns EOF if the end of the flow table has been
* reached, or a positive errno value on error. This function will not be
* called again once it returns nonzero within a given iteration (but the
* 'flow_dump_done' function will be called afterward).
*
* On success, if 'key' and 'key_len' are nonnull then '*key' and
* '*key_len' must be set to Netlink attributes with types ODP_KEY_ATTR_*
* representing the dumped flow's key. If 'actions' and 'actions_len' are
* nonnull then they should be set to Netlink attributes with types ODPAT_*
* representing the dumped flow's actions. If 'stats' is nonnull then it
* should be set to the dumped flow's statistics.
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
*
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
* All of the returned data is owned by 'dpif', not by the caller, and the
* caller must not modify or free it. 'dpif' must guarantee that it
* remains accessible and unchanging until at least the next call to
* 'flow_dump_next' or 'flow_dump_done' for 'state'. */
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
int (*flow_dump_next)(const struct dpif *dpif, void *state,
dpif: Eliminate "struct odp_flow" from client-visible interface. Following this commit, "struct odp_flow" and related data structures are only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:03:39 -08:00
const struct nlattr **key, size_t *key_len,
const struct nlattr **actions, size_t *actions_len,
dpif: Eliminate "struct odp_flow_stats" from client-visible interface. Following this commit, "struct odp_flow_stats" is only used in Linux-specific parts of OVS userspace code. This allows the actual Linux datapath interface to evolve more freely. Reviewed by Justin Pettit.
2011-01-26 07:11:50 -08:00
const struct dpif_flow_stats **stats);
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
/* Releases resources from 'dpif' for 'state', which was initialized by a
* successful call to the 'flow_dump_start' function for 'dpif'. */
int (*flow_dump_done)(const struct dpif *dpif, void *state);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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
/* Performs the 'actions_len' bytes of actions in 'actions' on the Ethernet
* frame specified in 'packet'. */
int (*execute)(struct dpif *dpif, const struct nlattr *actions,
size_t actions_len, const struct ofpbuf *packet);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Retrieves 'dpif''s "listen mask" into '*listen_mask'. Each ODPL_* bit
* set in '*listen_mask' indicates the 'dpif' will receive messages of the
* corresponding type when it calls the recv member function. */
int (*recv_get_mask)(const struct dpif *dpif, int *listen_mask);
/* Sets 'dpif''s "listen mask" to 'listen_mask'. Each ODPL_* bit set in
* 'listen_mask' indicates the 'dpif' will receive messages of the
* corresponding type when it calls the recv member function. */
int (*recv_set_mask)(struct dpif *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
/* Retrieves 'dpif''s sFlow sampling probability into '*probability'.
* Return value is 0 or a positive errno value. EOPNOTSUPP indicates that
* the datapath does not support sFlow, as does a null pointer.
*
Improve comments on interpretation of sFlow sampling probabilities. Suggested by Justin Pettit.
2010-01-08 16:44:43 -08:00
* '*probability' is expressed as the number of packets out of UINT_MAX to
* sample, e.g. probability/UINT_MAX is the probability of sampling a given
* packet. */
Initial implementation of sFlow. Tested very slightly with "ping" and "sflowtool -t | tcpdump -r -".
2010-01-04 13:08:37 -08:00
int (*get_sflow_probability)(const struct dpif *dpif,
uint32_t *probability);
/* Sets 'dpif''s sFlow sampling probability to 'probability'. Return value
* is 0 or a positive errno value. EOPNOTSUPP indicates that the datapath
* does not support sFlow, as does a null pointer.
*
Improve comments on interpretation of sFlow sampling probabilities. Suggested by Justin Pettit.
2010-01-08 16:44:43 -08:00
* 'probability' is expressed as the number of packets out of UINT_MAX to
* sample, e.g. probability/UINT_MAX is the probability of sampling a given
* packet. */
Initial implementation of sFlow. Tested very slightly with "ping" and "sflowtool -t | tcpdump -r -".
2010-01-04 13:08:37 -08:00
int (*set_sflow_probability)(struct dpif *dpif, uint32_t probability);
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
/* Translates OpenFlow queue ID 'queue_id' (in host byte order) into a
* priority value for use in the ODPAT_SET_PRIORITY action in
* '*priority'. */
int (*queue_to_priority)(const struct dpif *dpif, uint32_t queue_id,
uint32_t *priority);
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
/* Polls for an upcall from 'dpif'. If successful, stores the upcall into
* '*upcall'. Only upcalls of the types selected with the set_listen_mask
* member function should be received.
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -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
* The caller takes ownership of the data that 'upcall' points to.
* 'upcall->key' and 'upcall->actions' (if nonnull) point into data owned
* by 'upcall->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 that exist so far.)
*
* For greatest efficiency, 'upcall->packet' should have at least
* offsetof(struct ofp_packet_in, data) bytes of headroom.
*
* This function must not block. If no upcall is pending when it is
* called, it should return EAGAIN without blocking. */
int (*recv)(struct dpif *dpif, struct dpif_upcall *upcall);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
/* Arranges for the poll loop to wake up when 'dpif' has a message queued
* to be received with the recv member function. */
void (*recv_wait)(struct dpif *dpif);
datapath: Drop queue information from odp_stats. This queue information will be available through the kernel socket layer once we move over to Netlink socket as transports, so we might as well get rid of the redundancy. Signed-off-by: Ben Pfaff <blp@nicira.com> Acked-by: Jesse Gross <jesse@nicira.com>
2011-01-04 17:00:36 -08:00
/* Throws away any queued upcalls that 'dpif' currently has ready to
* return. */
void (*recv_purge)(struct dpif *dpif);
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
};
extern const struct dpif_class dpif_linux_class;
New implementation of userspace datapath, based on the netdev library.
2009-06-19 14:09:39 -07:00
extern const struct dpif_class dpif_netdev_class;
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
dpif: Rename "class" member to "dpif_class" for C++ compatibility. From partner.
2010-01-22 15:14:01 -08:00
#ifdef __cplusplus
}
#endif
dpif: Make dpifs abstract, to allow multiple datapath implementations. This commit initially introduces only a single datapath implementation, which is the same as the original one, but it paves the way for additional implementations, such as the upcoming userspace datapath.
2009-06-17 14:35:35 -07:00
#endif /* dpif-provider.h */
Reference in New Issue Copy Permalink