[ovs-dev] [ext-260 v3 4/5] ofp-errors: Implement OpenFlow 1.2+ experimenter error codes.

Alex Wang alexw at nicira.com
Tue Jun 25 16:50:56 UTC 2013


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 <blp at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130625/42334b85/attachment-0003.html>


More information about the dev mailing list