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

Ben Pfaff blp at nicira.com
Mon Jun 24 22:46:00 UTC 2013


On Mon, Jun 24, 2013 at 03:39:04PM -0700, Alex Wang wrote:
> On Mon, Jun 24, 2013 at 1:58 PM, Ben Pfaff <blp at 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.



More information about the dev mailing list