aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorBen Pfaff <blp@nicira.com>2010-01-20 13:52:42 -0800
committerBen Pfaff <blp@nicira.com>2010-01-20 14:33:28 -0800
commit56fd8edf80b6098289f9ddd94a6a4be3be648472 (patch)
tree511f04faaa212f53352df18e8decdbbcc7637854 /include
parent5aafcfe30afc383e53d8345cc781c644964d0e91 (diff)
sflow: Fix sFlow sampling structure.
According to Neil McKee, in an email archived at http://openvswitch.org/pipermail/dev_openvswitch.org/2010-January/000934.html: The containment rule is that a given sflow-datasource (sampler or poller) should be scoped within only one sflow-agent (or sub-agent). So the issue arrises when you have two switches/datapaths defined on the same host being managed with the same IP address: each switch is a separate sub-agent, so they can run independently (e.g. with their own sequence numbers) but they can't both claim to speak for the same sflow-datasource. Specifically, they can't both represent the <ifindex>:0 data-source. This containment rule is necessary so that the sFlow collector can scale and combine the results accurately. One option would be to stick with the <ifindex>:0 data-source but elevate it to be global across all bridges, with a global sample_pool and a global sflow_agent. Not tempting. Better to go the other way and allow each interface to have it's own sampler, just as it already has it's own poller. The ifIndex numbers are globally unique across all switches/datapaths on the host, so the containment is now clean. Datasource <ifindex>:5 might be on one switch, whille <ifindex>:7 can be on another. Other benefits are that 1) you can support the option of overriding the default sampling-rate on an interface-by-interface basis, and 2) this is how most sFlow implementations are coded, so there will be no surprises or interoperability issues with any sFlow collectors out there. This commit implements the approach suggested by Neil. This commit uses an atomic_t to represent the sampling pool. This is because we do want access to it to be atomic, but we expect that it will "mostly" be accessed from a single CPU at a time. Perhaps this is a bad assumption; we can always switch to another form of synchronization later. CC: Neil McKee <neil.mckee@inmon.com>
Diffstat (limited to 'include')
-rw-r--r--include/openvswitch/datapath-protocol.h5
1 files changed, 1 insertions, 4 deletions
diff --git a/include/openvswitch/datapath-protocol.h b/include/openvswitch/datapath-protocol.h
index 6d3e9007..b079f529 100644
--- a/include/openvswitch/datapath-protocol.h
+++ b/include/openvswitch/datapath-protocol.h
@@ -150,17 +150,14 @@ struct odp_msg {
* @sample_pool: Number of packets that were candidates for sFlow sampling,
* regardless of whether they were actually chosen and sent down to userspace.
* @n_actions: Number of "union odp_action"s immediately following this header.
- * @reserved: Pads the structure up to a 64-bit boundary. Should be set to
- * zero.
*
* This header follows &struct odp_msg when that structure's @type is
* %_ODPL_SFLOW_NR, and it is itself followed by an array of &union odp_action
* (the number of which is specified in @n_actions) and then by packet data.
*/
struct odp_sflow_sample_header {
- __u64 sample_pool;
+ __u32 sample_pool;
__u32 n_actions;
- __u32 reserved;
};
#define ODP_PORT_INTERNAL (1 << 0) /* This port is simulated. */