[ovs-dev] [#8024v2 3/5] Support matching and modifying IP ECN bits.

[Jesse Gross]

On Wed, Nov 9, 2011 at 12:27 AM, Justin Pettit <jpettit at nicira.com> wrote:
> On Nov 8, 2011, at 8:44 PM, Jesse Gross wrote:
>> I also notice that we print both the
>> individual DSCP/ECN components and the combined ToS in decimal in some
>> places as well, which is a little weird.
>
> Yes, this is because OpenFlow's treatment of DSCP/ECN/TOS is weird.  I'm trying to get it straightened out a bit in OpenFlow 1.2.
>
> The way I currently have it working is to have the kernel only understand a single "tos" element, which contains DSCP and ECN as you'd expect.  We print this in hex, since it's easier to parse out the DSCP bits from the ECN ones.
>
> In userspace, "nw_tos" is the DSCP bits shifted over by two (as if ECN were just being masked out of the actual TOS field).  This is how OpenFlow 1.0 and 1.1 define it, and we've just always printed it in decimal.  The new "nw_ecn" argument has a range of 0 to 3, so we just always print it in decimal.
>
> If you have a better suggestion, let me know.  I'm hoping that we can get some sanity in 1.2, and then we can just adopt that convention in the userspace.

Yeah, I remember that conversation.  What specifically caught my eye
though was the places (maybe there is only one...) where we print the
full ToS in decimal.  For example in flow.c:

@@ -539,8 +538,7 @@ flow_format(struct ds *ds, const struct flow *flow)
        ds_put_format(ds, " proto%"PRIu8
                          " tos%"PRIu8
                          " ip"IP_FMT"->"IP_FMT,
-                      flow->nw_proto,
-                      flow->tos & IP_DSCP_MASK,
+                      flow->nw_proto, flow->tos,
                      IP_ARGS(&flow->nw_src),
                      IP_ARGS(&flow->nw_dst));

Incrementals look good.