Hi Carlos,
Hmmm... It seems that your problem is whether Pyro4 can work on (or cooperate
with) GreanThreads.
I don't know much about Pyro4, if Pyro4 (client side at least) can work on
GreanThreads, you can call Pyro4's APIs on your Ryu application, I guess.
Ryu is designed for using non-blocking with eventlet and it is difficult to
draw their thread back to Native Threads, so if you need to communicate to
native threads, you need to some mechanism to realize it.
Anyway, the mixing of Native Threads and GreanThreads should be avoided, you
need to separate process (Ryu and Pyro4 client) first.
working on working on
non-blocking mode blocking mode
<=============> <===========================>
Ryu RyuApp Pyro4 Client Pyro4 Server
| event | | |
|------>| some mechanism(*) | |
| |------------------>| Request |
| | |-------->|
| | | Reply |
| | some mechanism(*) |<--------|
| |<------------------| |
For (*) in the above, if you prefer to use Queue, how about using Push/Pull
pattern of ZeroMQ?
The following describes the way to create a Queue like object with ZeroMQ.
http://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pushpull.html
Please note that, on Ryu, you need to use Eventlet's ZeroMQ instead of "pyzmq",
but the usage seems to be almost the same.
http://eventlet.net/doc/modules/zmq.html
Thanks,
Iwase
On 2017年12月21日 09:48, Carlos Ferreira wrote:
Thank you Iwase.
I was actually thinking in using queues to synchronise information
between Ryu's threads and native threads, since I'm also using Pyro4
to communicate with another service.
But my doubt here is, how can I suspend a Ryu thread and make it wait
for a message to arrive at a queue?
I have never used ZeroMQ and I wanted to use a simple mechanism, like
the native Python queue.Queue, for example.
Carlos
On 20 December 2017 at 23:45, Iwase Yusuke <iwase.yusu...@gmail.com> wrote:
Hi Carlos,
Please let me confirm your issue first.
Your question is how to suspend the current thread waiting for some works
finished (REST request? or other thread?), right?
To suspend your threads using ryu.lib.hub.spawn, you can use
"eventlet.event"
which is similar to a Queue or threading.Lock.
http://eventlet.net/doc/modules/event.html
For example:
Ryu xxx_handler thread worker
| Event | | |
|------>| | |
| | hub.spawn | |
| |---------->| |
| | | request some |
| | |------------->|
| | | response |
| | FlowMod |<-------------|
| | request | |
|<------------------| |
| | | |
On this situation, your problem is mixing the Native Threads and the
GreenThreads?
As far as I know, the Native Threads behave (normally) as IO blocking
threads
and Ryu's threads (using ryu.lib.hub.spawn) behave as non-blocking threads.
Generally, it is not recommended to mix blocking and non-blocking in the
same
process, if these need to cooperate, I guess some APIs like socket (TCP,
REST or
so), file, messaging queue(http://eventlet.net/doc/zeromq.html) is better
way to
communicate between blocking and non-blocking.
Does someone know more better way?
Thanks,
Iwase
On 2017年12月20日 07:52, Carlos Ferreira wrote:
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
------------------------------------------------------------------------------
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
