OpenFlow 1.3 says that the band_types member of struct ofp_meter_features
is a bitmap of OFPMBT_* values. The OFPMBT_* values are 1-based, so
until now, to avoid wasting bit 0, OVS mapped an OFPMBT_* with value 1 to
bit 0, value 2 to bit 1, and so on. However, according to
http://openvswitch.org/pipermail/dev/2013-July/029666.html,
other OpenFlow implementations directly translate value 1 to bit 1,
value 2 to bit 2, and so on. This commit changes Open vSwitch to use this
more common interpretation.
A request for clarification of this issue in the OpenFlow standard has been
filed with the ONF Extensibility Working Group as issue EXT-345.
Reported-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
static const char *
ofputil_meter_band_types_to_name(uint32_t bit)
{
static const char *
ofputil_meter_band_types_to_name(uint32_t bit)
{
- /*
- * Note: Meter band types start from 1. We assume that the lowest bit
- * in the band_types corresponds to DROP band type (1).
- */
- case 1 << (OFPMBT13_DROP - 1): return "drop";
- case 1 << (OFPMBT13_DSCP_REMARK - 1): return "dscp_remark";
+ case 1 << OFPMBT13_DROP: return "drop";
+ case 1 << OFPMBT13_DSCP_REMARK: return "dscp_remark";
AT_KEYWORDS([ofp-print OFPT_STATS_REPLY])
AT_CHECK([ovs-ofctl ofp-print "\
04 13 00 20 00 00 00 02 00 0b 00 00 00 00 00 00 \
AT_KEYWORDS([ofp-print OFPT_STATS_REPLY])
AT_CHECK([ovs-ofctl ofp-print "\
04 13 00 20 00 00 00 02 00 0b 00 00 00 00 00 00 \
-00 01 00 00 00 00 00 03 00 00 00 0F 10 02 00 00 \
+00 01 00 00 00 00 00 06 00 00 00 0F 10 02 00 00 \
"], [0], [dnl
OFPST_METER_FEATURES reply (OF1.3) (xid=0x2):
max_meter:65536 max_bands:16 max_color:2
"], [0], [dnl
OFPST_METER_FEATURES reply (OF1.3) (xid=0x2):
max_meter:65536 max_bands:16 max_color:2