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
>>
>
--
Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro - Portugal
Work E-mail - c...@av.it.pt
Skype & GTalk -> carlosmf...@gmail.com
LinkedIn -> http://www.linkedin.com/in/carlosmferreira
------------------------------------------------------------------------------
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
