<div dir="ltr">Sorry for the delayed reply, Ben<div><br></div><div style>I'm about to conduct a final review and then pass the patch. Thanks,</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 9:10 AM, Ben Pfaff <span dir="ltr"><<a href="mailto:blp@nicira.com" target="_blank">blp@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jun 25, 2013 at 08:32:34AM -0700, Alex Wang wrote:<br>
> > > > > "<br>
> > > > > oem = ofpbuf_put_uninit(buf, sizeof *oem);<br>
> > > > > oem->type = htons(NXET_VENDOR);<br>
> > > > > "<br>
> > > > ><br>
> > > > > In the "ovs_hex_dump()" function which prints the encoded header, it<br>
> > uses<br>
> > > > > "fprintf(stream, "%02hhx"<br>
> > > > > to print it and the value is again in host order (if %x is used, it<br>
> > will<br>
> > > > > print the network order).<br>
> > > > ><br>
> > > > > So I want to ask what is the use of "hhx" here? and why can't we get<br>
> > rid<br>
> > > > of<br>
> > > > > htons and use %x in<br>
> > > > > ovs_hex_dump?<br>
> > > ><br>
> > > > 'oem' is a "wire format" type, and its member 'type' is an ovs_be16,<br>
> > > > so to appropriately assign it a value it must be converted to network<br>
> > > > byte order first. That is why htons() is used.<br>
> > > ><br>
> > > > ovs_hex_dump() dumps the contents of a structure byte by byte. Its<br>
> > > > output will depend on the byte order of the underlying data. In this<br>
> > > > case the data is in network byte order, so the byte-by-byte dump will<br>
> > > > reflect that.<br>
> > > ><br>
> > > > 'hh' doesn't have anything to do with byte order. It means that the<br>
> > > > argument is a char type.<br>
> > > ><br>
> > ><br>
> > ><br>
> > > Thanks for the explanation. My previous experiment was wrong. And I found<br>
> > > out that the if "htons" is not used the "0xb0c2" when converted to "uint8<br>
> > > buf[2]" will be "buf[0]=0xc2" and "buf[1]=0xb0". So I think the "htons"<br>
> > > also helps preserve the hex order. right?<br>
> ><br>
> > It depends on the machine's endianness. You're using x86 or x86-64 (I<br>
> > guess), which is little-endian, so you see what you're reporting. If<br>
> > you were using a SPARC or some other big-endian machine, the htons()<br>
> > would have no effect and you would see no difference, because host and<br>
> > network byte order are the same on a big-endian machine.<br>
> ><br>
><br>
> Thanks Ben,<br>
><br>
> This makes sense,<br>
<br>
</div></div>Thanks.<br>
<br>
Are you satisfied with this patch series, then?<br>
</blockquote></div><br></div>