Sorry for the delayed reply, Ben I'm about to conduct a final review and then pass the patch. Thanks,
On Tue, Jun 25, 2013 at 9:10 AM, Ben Pfaff <b...@nicira.com> wrote: > On Tue, Jun 25, 2013 at 08:32:34AM -0700, Alex Wang wrote: > > > > > > " > > > > > > 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. > > > > > > > Thanks Ben, > > > > This makes sense, > > Thanks. > > Are you satisfied with this patch series, then? >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
