OF1.2 and up include every OXM in Match's supports() function. This seems to be rooted in the fact that java_gen/templates/custom/OFMatchV3Ver12.java, OFMatchV3Ver13.java, OFMatchV3Ver14.java, and OFMatchV3Ver15.java all delegate to OFMatchV3.java, which pulls possible/valid OXMs from model.oxm_map.values(), line 37 of OFMatchV3.java.
@andi-bigswitch Do you have any thoughts about the best way to fix this? Brute force would be to create a separate supports() function for each OpenFlow version in the version-specific Match class templates. But, I have a feeling there might be something in Loxi that tracks this already and maybe the wrong oxm_map is being referenced. Is there a version-specific list of OXMs that's compiled when Loxi parses the OpenFlow input files? Maybe this can be referenced instead in the OFMatchV3.java template, rather than the global list of OXMs.
OF1.2 and up include every OXM in Match's supports() function. This seems to be rooted in the fact that java_gen/templates/custom/OFMatchV3Ver12.java, OFMatchV3Ver13.java, OFMatchV3Ver14.java, and OFMatchV3Ver15.java all delegate to OFMatchV3.java, which pulls possible/valid OXMs from model.oxm_map.values(), line 37 of OFMatchV3.java.
@andi-bigswitch Do you have any thoughts about the best way to fix this? Brute force would be to create a separate supports() function for each OpenFlow version in the version-specific Match class templates. But, I have a feeling there might be something in Loxi that tracks this already and maybe the wrong oxm_map is being referenced. Is there a version-specific list of OXMs that's compiled when Loxi parses the OpenFlow input files? Maybe this can be referenced instead in the OFMatchV3.java template, rather than the global list of OXMs.