On Wed, Nov 9, 2011 at 12:27 AM, Justin Pettit <jpet...@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
