Hi, all
I do not know whether it is suitable to post it here, just wanting somebody who
is familiar with the code to confirm it.
While I was reading the open source of OpenVswitch from
"CPqD-of12softswitch-797b816", in the file ofl-structs-unpack.c, the following
function:
static ofl_err
ofl_structs_oxm_match_unpack(struct ofp_match* src, uint8_t* buf, size_t *len,
struct ofl_match **dst){
int error = 0;
struct ofpbuf *b = ofpbuf_new(0);
struct ofl_match *m = (struct ofl_match *) malloc(sizeof(struct
ofl_match));
m->header.type = ntohs(src->type);
*len -= ROUND_UP(ntohs(src->length),8); /* lifengkai, this is the length of
the instructions */
if(ntohs(src->length) > sizeof(struct ofp_match)){
/* ofpbuf, buf to the oxm_fields, length of all the oxm_fields */
ofpbuf_put(b, buf, ntohs(src->length) - (sizeof(struct ofp_match) -4));
error = oxm_pull_match(b, m, ntohs(src->length) - (sizeof(struct
ofp_match) -4));
m->header.length = ntohs(src->length) - 4;
}
else m->header.length = 0;
ofpbuf_delete(b);
*dst = m;
return error;
}
Why the header.length is reassigned to this value, as I see it has already been
assigned in the function "parse_oxm_entry " for different cases, which is
called deeper by "oxm_pull_match".
I think the m->header.length in the "ofl" datapath layer should not be the
length of the "ofp" layer.
Of courcse, the OpenVswitch works well, as we have several test, we printed the
value of m->header.length, it is the same as the src->length.
Regards,
Fengkai Li
_______________________________________________
openflow-discuss mailing list
openflow-discuss@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
