As vlan tags are 32-bits-long, at least we don't need to bother with those. But I guess the padding would be different for Ethernet II, and LLC/SNAP, given the requirement. (I'm not going to guess the right padding lengths at this time of the day). But the question is: if the padding is different, how does the controller know where the packet starts? - confused -
Z. > -----Original Message----- > From: yap...@gmail.com [mailto:yap...@gmail.com] On Behalf Of kk yap > Sent: Monday, August 29, 2011 4:44 PM > To: Zoltán Lajos Kis > Cc: Ben Pfaff; openflow-disc...@mailman.stanford.edu > Subject: Re: [openflow-discuss] OpenFlow 1.1 ofp_packet_in > padding clarification > > 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=seccha > > n/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
