On Mon, Jun 24, 2013 at 03:39:04PM -0700, Alex Wang wrote: > On Mon, Jun 24, 2013 at 1:58 PM, Ben Pfaff <b...@nicira.com> wrote: > > > dnl Write-Metadata duplicated. > > > > -# bad OF1.1 instructions: OFPBAC_UNSUPPORTED_ORDER > > > > +# bad OF1.1 instructions: NXBIC_DUP_INSTRUCTION > > > > 0002 0018 00000000 fedcba9876543210 ff00ff00ff00ff00 0002 0018 > > 00000000 > > > > fedcba9876543210 ff00ff00ff00ff00 > > > > > > > > > Want to ask what does NXBIC stand for? Also, I didn't find the definition > > > of this macro, even before applying patch 5/5. Want to know how and where > > > is it defined? > > > > Oops. This is a mistake. This change should not be in this patch. > > I've removed it. > > I'm still curious why the test still passes. Could you explain more? Thanks
It didn't pass for me. I must have neglected to rerun "make check" on that particular commit. > > > followed the code > > > and decoded it myself. And I really want to ask an unrelated question. > > > > > > I saw in the "ofperr_encode_msg__()" function in "lib/ofp-error.c", the > > > fields are converted to > > > network order, like below: > > > > > > " > > > oem = ofpbuf_put_uninit(buf, sizeof *oem); > > > oem->type = htons(NXET_VENDOR); > > > " > > > > > > In the "ovs_hex_dump()" function which prints the encoded header, it uses > > > "fprintf(stream, "%02hhx" > > > to print it and the value is again in host order (if %x is used, it will > > > print the network order). > > > > > > So I want to ask what is the use of "hhx" here? and why can't we get rid > > of > > > htons and use %x in > > > ovs_hex_dump? > > > > 'oem' is a "wire format" type, and its member 'type' is an ovs_be16, > > so to appropriately assign it a value it must be converted to network > > byte order first. That is why htons() is used. > > > > ovs_hex_dump() dumps the contents of a structure byte by byte. Its > > output will depend on the byte order of the underlying data. In this > > case the data is in network byte order, so the byte-by-byte dump will > > reflect that. > > > > 'hh' doesn't have anything to do with byte order. It means that the > > argument is a char type. > > > > > Thanks for the explanation. My previous experiment was wrong. And I found > out that the if "htons" is not used the "0xb0c2" when converted to "uint8 > buf[2]" will be "buf[0]=0xc2" and "buf[1]=0xb0". So I think the "htons" > also helps preserve the hex order. right? It depends on the machine's endianness. You're using x86 or x86-64 (I guess), which is little-endian, so you see what you're reporting. If you were using a SPARC or some other big-endian machine, the htons() would have no effect and you would see no difference, because host and network byte order are the same on a big-endian machine. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
