Possibly Wrong bits comparison for DSCP value in parse_oxm_entry

[nikchez01]

Hi,

Please correct me if I am wrong:
Function: parse_oxm_entry.
case OFI_OXM_OF_IP_DSCP:{
if (*v & 0xc0) {
return ofp_mkerr(OFPET_BAD_MATCH, OFPBMC_BAD_VALUE);

I think DSCP is MSB 6 bits value. So we should check for 2 LSB non-zero bits. So it should be:
if (*v & 0x03) {

[ederlf]

That would be true if the operation is done with the value from the ip packet. That is just a check for an out of bound value of the IP DSCP in an OXM value.
The minimum possible value is 8 bits, so the DSCP value is a BAD_VALUE if there is any bit set beyond the allowed six bits.

[nikchez01]

I understand. As far as I remember, when I tested DSCP match, Protocol information coming from nbee functions were not 2 bits left shifted (for DSCP) . So when OXM value (2 bits shifted) was compared to Packet protocol info in udatapath, it was giving match as NG.

But now I checked nbee code and it is 2 bits left shifted. Let me re-run the test again and get back to you with additional info.

[ederlf]

@nikchez01, the OXM value is not shifted, understand that the DSCP value is just a value, it is set alone as an OXM value, not extracted from the IP packet. On Nbee it is shifted because it comes along the whole IP TOS field which is 8, being the 6 rightmost bits the DSCP, so it is shifted.

If there is an error in the DSCP matching, it would have been better reporting it directly.