Hi, Thanks for the feedback. It seems this never made it to the 1.0 switch [1] or nox [2] however. I was just wondering if this padding has ever been implemented by someone; and if I did implement ofp_packet_in according to the spec., would I lose compatibility with everyone else :).
Also you are correct, the comment "Because of padding, offsetof(struct ofp_packet_in, data) == sizeof(struct ofp_packet_in) - 2." is valid. It is just confusing, as I thought "because of padding" is referring to the padding of the payload, but in fact it refers to the C99 padding for "flexible array members". Regards, Zoltan. [1] http://yuba.stanford.edu/git/gitweb.cgi?p=openflow.git;a=blob;f=secchan/in-band.c#l259 [2] http://noxrepo.org/cgi-bin/gitweb.cgi?p=nox;a=blob;f=src/lib/openflow-event.cc#l65 > -----Original Message----- > From: Ben Pfaff [mailto:b...@nicira.com] > Sent: Friday, August 26, 2011 7:43 PM > To: Zoltán Lajos Kis > Cc: openflow-disc...@mailman.stanford.edu > Subject: Re: [openflow-discuss] OpenFlow 1.1 ofp_packet_in > padding clarification > > On Fri, Aug 26, 2011 at 11:18:27AM +0200, Zolt?n Lajos Kis wrote: > > I need some clarification on the data field for > ofp_packet_in. The OF > > 1.1 spec contains the following comment: > > > > /* Ethernet frame, halfway through 32-bit word, so the IP header is > > 32-bit aligned. The amount of data is inferred from the > length field > > in the header. Because of padding, offsetof(struct ofp_packet_in, > > data) == sizeof(struct ofp_packet_in) - 2. */ > > > > Does this supposed to mean that the data field should start > with two > > bytes of padding (i.e. junk data), and the datapath packet > should only > > follow after that (so that the ethernet header now ends after > > 16 bytes, so the IP header will start at a 32bit boundary)? > > Yes. > > > In other words, the packet format should really be: > > ... > > uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */ > > uint8_t table_id; /* ID of the table that was looked up */ uint8_t > > pad[2]; uint8_t data[0]; } > > > > But in essence we are afraid the "implementor" would be dumb enough > > not to use e.g. the packed attribute, and so the compiler > would mess > > things up, we instead moved the padding into the comments section? > > It is usually a mistake to use the "packed" attribute if one > does not have to, because it slows down access even to > properly aligned data on many non-x86 architectures. > > Another reason that the header file does not used "packed" is > that it is a GCC-specific feature. Most compilers have a > similar feature, but > __attribute__((packed)) isn't necessarily the correct way to > use it (some use a #pragma, for example). > > > Also I suppose the equation in the comment should read > something like: > > data_len = ofp_header.length - sizeof(struct ofp_packet_in) - 2. > > The comment was correct for the OpenFlow 1.0 version of the > structure, but the structure was changed for 1.1 without > updating the comment. > > > What's the case with packet_out; should the data field also contain > > some implicit padding there for IP header alignment? > > For consistency, it should, but in fact it does not. > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
