Iwase, can you help me here, please?
Thank you!
Carlos Ferreira
On 18 December 2017 at 11:16, Carlos Ferreira <carlosmf...@gmail.com> wrote:
> Hmm, suspending all Ryu activities that is precisely what I was trying to
> avoid.
>
> Ok I have another idea. Instead of having the coroutine waiting for
> some work to be processed, what if I have a Python thread creating a
> new coroutine using ryu.lib.hub.spawn, which will then active the
> necessary flows when a decision is ready to be implemented?
>
> I had issues in the past, when mixing Threads and the greenlet
> coroutines, having problems when sharing information between them.
>
> Thank you Iwase, for your help!
>
>
> On 18 December 2017 at 05:39, Iwase Yusuke <iwase.yusu...@gmail.com> wrote:
>> Hi Carlos,
>>
>> Well, as far as I know, Ryu does not provides the features for suspending
>> the
>> specific activities (e.g., threads) of Ryu, so I guess you can only suspend
>> all activities at the same time.
>>
>> Just an idea, the following suspends all Ryu activities when calling sleep()
>> and prevents other threads getting executed.
>> The following uses the "non-patched" time module to suspend greanthread.
>> If you need some locks, please use threading.Lock instead of time.sleep().
>>
>>
>> $ git diff
>> diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
>> index 06a5d0e..316ee37 100644
>> --- a/ryu/app/simple_switch_13.py
>> +++ b/ryu/app/simple_switch_13.py
>> @@ -22,6 +22,9 @@ from ryu.lib.packet import packet
>> from ryu.lib.packet import ethernet
>> from ryu.lib.packet import ether_types
>>
>> +from eventlet import patcher
>> +orig_time = patcher.original('time')
>> +
>>
>> class SimpleSwitch13(app_manager.RyuApp):
>> OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
>> @@ -29,6 +32,7 @@ class SimpleSwitch13(app_manager.RyuApp):
>> def __init__(self, *args, **kwargs):
>> super(SimpleSwitch13, self).__init__(*args, **kwargs)
>> self.mac_to_port = {}
>> + self.is_something_done = False
>>
>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
>> def switch_features_handler(self, ev):
>> @@ -63,8 +67,19 @@ class SimpleSwitch13(app_manager.RyuApp):
>> match=match, instructions=inst)
>> datapath.send_msg(mod)
>>
>> + def _do_something_with_global_blocking(self):
>> + if self.is_something_done:
>> + return
>> +
>> + self.logger.info('waiting for done of something...')
>> + orig_time.sleep(10)
>> + self.is_something_done = True
>> + self.logger.info('done.')
>> +
>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
>> def _packet_in_handler(self, ev):
>> + self._do_something_with_global_blocking()
>> +
>> # If you hit this you might want to increase
>> # the "miss_send_length" of your switch
>> if ev.msg.msg_len < ev.msg.total_len:
>>
>>
>> With the above modification, simple_switch_13.py blocks all Ryu activities
>> while
>> 10 seconds, and Packet-In event will not be handled until done.
>>
>> $ ryu-manager ryu/app/simple_switch_13.py
>> loading app ryu/app/simple_switch_13.py
>> loading app ryu.controller.ofp_handler
>> instantiating app ryu/app/simple_switch_13.py of SimpleSwitch13
>> instantiating app ryu.controller.ofp_handler of OFPHandler
>> waiting for done of something...
>> done.
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1
>> packet in 1 82:3d:bb:d5:d6:ba c2:09:7b:d2:6c:a2 2
>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1
>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1
>> ...(snip)...
>>
>> mininet> h1 ping h2
>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
>> From 10.0.0.1 icmp_seq=1 Destination Host Unreachable # not handled as
>> sleeping
>> From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=4 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=5 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=6 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=7 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=8 Destination Host Unreachable
>> From 10.0.0.1 icmp_seq=9 Destination Host Unreachable
>> 64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=2005 ms
>> 64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=996 ms
>> 64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=0.170 ms
>> 64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=0.055 ms
>> 64 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=0.059 ms
>> 64 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=0.066 ms
>> ^C
>> --- 10.0.0.2 ping statistics ---
>> 15 packets transmitted, 6 received, +9 errors, 60% packet loss, time 14054ms
>> rtt min/avg/max/mdev = 0.055/500.491/2005.751/765.266 ms, pipe 3
>>
>>
>> Please note that this approach will suspend "all" activities of Ryu, if a
>> lot of
>> Packet-In events curred while blocking, these event will invoked
>> immediately.
>>
>>
>> Thanks,
>> Iwase
>>
>>
>>
>> On 2017年12月15日 06:03, Carlos Ferreira wrote:
>>>
>>> I work with real switches (Zodiac FX).
>>>
>>> Depending on the Events, wether is Packet_In or other Events, I want
>>> to take different kinds of actions.
>>> Some of these actions, require contacting a different system
>>> component, outside of the Ryu scope.
>>> What I want, is to have a way to suspend the greenlet execution and
>>> continue with the following Events processing, while the outside
>>> system does its thing. Once the outside system returns with the
>>> required data, the greenlet will resume the processing.
>>>
>>> Carlos
>>>
>>>
>>> On 14 December 2017 at 20:37, <marcosab...@inf.ufg.br> wrote:
>>>>
>>>> When you subscribe an event (with @override) while switch is connect you
>>>> receive this event. You can ignore these events implementing a logic
>>>> according your application. But when you ignore an event, for exemple
>>>> Packet_IN, you loss the packets that enter in switch.
>>>>
>>>> Can you explain more your problem? You work with real switch or OVS?
>>>>
>>>> Citando Carlos Ferreira <carlosmf...@gmail.com>:
>>>>
>>>>> Hello to all!
>>>>>
>>>>> Is it possible to suspend a Ryu Coroutine event? For example, suspend
>>>>> the execution of the Packet_IN handler, while waiting for an event,
>>>>> signal or condition?
>>>>>
>>>>> I need to know how can I do this, because I need to execute some
>>>>> algorithms, which may take some time and depend upon resources outside
>>>>> of the application. I wanted for the coroutine to wait until it gets a
>>>>> result, but I didn't want to stall the entire event pipeline.
>>>>>
>>>>> Thank you!
>>>>> Carlos Ferreira
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Ryu-devel mailing list
>>>>> Ryu-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Ryu-devel mailing list
>>>> Ryu-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Ryu-devel mailing list
>>> Ryu-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>
>>
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
