On Tue, 15 Oct 2013 17:14:16 +0900 Yoshihiro Kaneko <[email protected]> wrote:
> 2013/10/15 YAMAMOTO Takashi <[email protected]>: >>> 2013/10/15 YAMAMOTO Takashi <[email protected]>: >>>>> 2013/10/10 YAMAMOTO Takashi <[email protected]>: >>>>>>> OVS has not yet supported table-miss flow, but this patch changes >>>>>>> simple_switch_13 to install table-miss flow entry in accordance >>>>>>> with OF1.3 spec. >>>>>>> >>>>>>> Signed-off-by: Yoshihiro Kaneko <[email protected]> >>>>>>> --- >>>>>>> ryu/app/simple_switch_13.py | 42 >>>>>>> ++++++++++++++++++++++++++---------------- >>>>>>> 1 file changed, 26 insertions(+), 16 deletions(-) >>>>>>> >>>>>>> diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py >>>>>>> index 18f874c..b211498 100644 >>>>>>> --- a/ryu/app/simple_switch_13.py >>>>>>> +++ b/ryu/app/simple_switch_13.py >>>>>>> @@ -13,12 +13,9 @@ >>>>>>> # See the License for the specific language governing permissions and >>>>>>> # limitations under the License. >>>>>>> >>>>>>> -import logging >>>>>>> -import struct >>>>>>> - >>>>>>> from ryu.base import app_manager >>>>>>> from ryu.controller import ofp_event >>>>>>> -from ryu.controller.handler import MAIN_DISPATCHER >>>>>>> +from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER >>>>>>> from ryu.controller.handler import set_ev_cls >>>>>>> from ryu.ofproto import ofproto_v1_3 >>>>>>> from ryu.lib.packet import packet >>>>>>> @@ -32,18 +29,29 @@ class SimpleSwitch13(app_manager.RyuApp): >>>>>>> super(SimpleSwitch13, self).__init__(*args, **kwargs) >>>>>>> self.mac_to_port = {} >>>>>>> >>>>>>> - def add_flow(self, datapath, port, dst, actions): >>>>>>> + @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER) >>>>>>> + def switch_features_handler(self, ev): >>>>>>> + datapath = ev.msg.datapath >>>>>>> + ofproto = datapath.ofproto >>>>>>> + parser = datapath.ofproto_parser >>>>>>> + >>>>>>> + # install table-miss flow entry >>>>>>> + match = parser.OFPMatch() >>>>>>> + actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER, >>>>>>> + ofproto.OFPCML_NO_BUFFER)] >>>>>> >>>>>> why no_buffer? >>>>> >>>>> packet_in handler extracts source mac address and destination >>>>> mac address from msg.data. >>>> >>>> sure, but the current value (128 bytes) is enough for the purpose, >>>> isn't it? >>> >>> Besides, msg.data is used by Packet-Out to send a packet. >>> I think that the entire packet is needed when buffer_id is invalid. >> >> it shouldn't be a problem because, if a switch failed to allocate a buffer >> for some reasons, it should send us the entire packet regardless of max_len. > > Thanks for the clarification. > I understand. > >> >> however, at a glance at OVS code, it seems to send us packets unbuffered >> but truncated for reason=action. i think it's their bug. > > Hmm, we cannot reach a good example for OF1.3... Let's assume that buffer_id is valid and keep the code simple (maybe adding a comment on this might be a good idea though). We can drop a packet if we hit an invalid buffer_id. In the real world, hardware switches could sometimes drop packets for some reason. It's extremely undesirable but not the end of the world. I don't think that it's a good idea to make this example code too complicated to avoid such corner case. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
