[ovs-dev] [PATCH] gre: Use struct for parsing GRE header.

[Jesse Gross]

On Thu, Jul 15, 2010 at 2:47 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Thu, Jul 15, 2010 at 02:16:11PM -0700, Jesse Gross wrote:
> > On Thu, Jul 15, 2010 at 2:05 PM, Ben Pfaff <blp at nicira.com> wrote:
> >
> > > On Thu, Jul 15, 2010 at 1:53 PM, Jesse Gross <jesse at nicira.com> wrote:
> > > > On Thu, Jul 15, 2010 at 1:46 PM, Ben Pfaff <blp at nicira.com> wrote:
> > > >>
> > > >> On Thu, Jul 15, 2010 at 01:07:11PM -0700, Jesse Gross wrote:
> > > >> > GRE is a somewhat annoying protocol because the header is variable
> > > >> > length.  However, it does have a few fields that are always
> present
> > > >> > so we can make the parsing seem less magical by using a struct for
> > > >> > those fields instead of building it up field by field.
> > > >>
> > > >> The "flags" field appears to be in host byte order.  Is that right?
> > > >
> > > > It's more an array of bits than an actual number with endianness but
> > > network
> > > > byte order is probably more correct.
> > >
> > > It goes comes in and goes out on the wire, right?  So isn't it
> important to
> > > have
> > > those bits in the right places, just like, say, the flag bits in the
> TCP
> > > header?
> >
> > Yeah, you're right that network byte order is more correct and I updated
> it
> > to be __be16.  Mentally I just see it as more an array of bits that
> always
> > gets processed in a certain way, much like an array of individual bytes
> > doesn't haven't endianness per se, even if position is still important.
> >  It's not really a big deal though.
>
> It's good to get the type right, but don't we need a bunch of htons()s
> sprinkled around too?
>

I keep the constants for the different flags in network byte order and then
just directly AND them together, so there is no need to actually do the
conversion (actually I don't even define them myself, they're in
linux/if_tunnel.h).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100715/a65a9ed5/attachment-0003.html>