Hi, Just to satisfy my own curiosity, won't the padding require the switch to parse the packet to insert the padding before sending it to the switch? This seems counter-intuitive since the packet is delivered to the controller unparsed according to the spec.
However, it might actually make sense for the switch to parse the packet before sending it to the controller (if resources and implementations can afford it). At least this would provide some consistency for malformed packets. Regards KK 2011/8/29 Zoltán Lajos Kis <zoltan.lajos....@ericsson.com>: > 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 > _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
