[openflow-discuss] can openflow install on xen？
Hi，all！ I want to use xen on centos，but the kernel of centos is 2.6.18，and I saw that Compile Fresh Kernel for Regression Suite The OpenFlow regression suite does not require any particular kernel version, but if you're using a VM and would like to run the tests with no external hardware, using virtual ethernet pairs works well. Veth pairs were added to the Linux kernel as of version 2.6.24, but the standard RHEL/CentOS kernels currently derive from 2.6.18, so you'll need to build and install a newer kernel version. so here is my question： 1.can openflow install on VM of xen？ 2. If openflow can install on VM of xen，should the kernel of centos must be upgraded to 2.6.24？ Thank you 2011-08-29 linbo ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
[openflow-discuss] OpenFlow 1.1 pipeline clarification
Hi, One more thing that is a bit ambigouos, which I'd like to get clarified (or at least hear other people's opinion about it). If I have the following scenario: - A flow in table 0 matches the incoming packet - puts an output-action on port 0 to the action set - sends the packet to table 1 - In table 1 there is no matching entry - the table default config is to send a packet_in At this point, should the switch send the packet out on port 0 (based on flow 0), or send a packet_in (because of the table config)? I think both are valid, and make sense. The spec. (bottom of pg. 6.) seems to suggest the latter, but there is a direct test-case for the former [1]. So the question is: which is the expected behavior; and if the answer is "either", should we add a new table config, like OFPTC_TABLE_MISS_EXECUTE, to make explicit distinction between the two possible? Regards, Zoltan. [1] http://yuba.stanford.edu/git/gitweb.cgi?p=oftest.git;a=blob;f=tests/multi-table.py;h=7616cdff3435e2d8efbb5427b1f11bbcf459af53;hb=oft-1.1#l37 ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
Re: [openflow-discuss] OpenFlow 1.1 ofp_packet_in padding clarification
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
Re: [openflow-discuss] OpenFlow 1.1 pipeline clarification
2011/8/29 Zoltán Lajos Kis : I think the expected behavior is to execute the table configured default, i.e., one of : OFPTC_TABLE_MISS_CONTROLLER , /* Send to controller. */ OFPTC_TABLE_MISS_CONTINUE /* Continue to the next table */ OFPTC_TABLE_MISS_DROP But that does seem to preclude "stop processing and just execute current action set" . > So the question is: which is the expected behavior; and if the answer is > "either", should we add a new table config, like > OFPTC_TABLE_MISS_EXECUTE, to make explicit distinction between the two > possible? IMHO, the behavior/spec is clear, but the current spec does not allow you to do the very reasonable thing that you want. Given that, I think adding a OFPTC_TABLE_MISS_EXECUTE is probably the right thing. My first thought was to say that "if that's the behavior the controller wants, you can always specific a low-priority match all in table 1", but it's my understanding that it's not simple to specify a "match all" for all types of table hardware, e.g., I'm not sure you could do that with a non-TCAM-based L2 table, so another OFPTC_TABLE_MISS_* constant seems like the right thing. Good catch Zoltan, - Rob . ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
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 : > 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
Re: [openflow-discuss] OpenFlow 1.1 pipeline clarification
Thanks for the feedback. In fact it is a joint discovery with some of my colleagues; basically I implemented the "latter", when fixing the switch against the oftest cases, while they expected the "former", based on the specification :o). Anyway, I'll make a somewhat formal proposal so that it can make it to OpenFlow x.y. Regards, Zoltan. > -Original Message- > From: Rob Sherwood [mailto:rob.sherw...@bigswitch.com] > Sent: Monday, August 29, 2011 4:41 PM > To: Zoltán Lajos Kis > Cc: openflow-disc...@mailman.stanford.edu > Subject: Re: [openflow-discuss] OpenFlow 1.1 pipeline clarification > > 2011/8/29 Zoltán Lajos Kis : > > I think the expected behavior is to execute the table > configured default, i.e., one of : > OFPTC_TABLE_MISS_CONTROLLER , /* Send to controller. */ > OFPTC_TABLE_MISS_CONTINUE /* Continue to the > next table */ > OFPTC_TABLE_MISS_DROP > > But that does seem to preclude "stop processing and just > execute current action set" . > > > So the question is: which is the expected behavior; and if > the answer > > is "either", should we add a new table config, like > > OFPTC_TABLE_MISS_EXECUTE, to make explicit distinction > between the two > > possible? > > IMHO, the behavior/spec is clear, but the current spec does > not allow you to do the very reasonable thing that you want. > Given that, I think adding a OFPTC_TABLE_MISS_EXECUTE is > probably the right thing. > My first thought was to say that "if that's the behavior the > controller wants, you can always specific a low-priority > match all in table 1", but it's my understanding that it's > not simple to specify a "match all" for all types of table > hardware, e.g., I'm not sure you could do that with a > non-TCAM-based L2 table, so another > OFPTC_TABLE_MISS_* constant seems like the right thing. > > Good catch Zoltan, > > - Rob > . > ___ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
Re: [openflow-discuss] OpenFlow 1.1 ofp_packet_in padding clarification
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 : > > 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 > > > __
