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 [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
