Alright thank you. So I guess there is no method to send out multiple flows
in parallel by Ryu?
On Tue, Apr 25, 2017 at 5:22 AM, Tao Li <tao...@tu-dresden.de> wrote:
> I think, even if you only start one single process to add a flow, the
> connection (object) between the controller and switch is still owned by the
> root process, in which you start your delegate process. In the case that
> you want to add more computation capacity, maybe you can perform the
> computation inside the additionally created processes and get the results
> back to the root process to send out to the switches. But this approach
> cannot increase Ryu’s capacity of accepting/sending OF messages, as far as
> I can see.
>
> Best regards,
> Tao
>
> On 25 Apr 2017, at 05:12, Yiwen Shen <ys2...@columbia.edu> wrote:
>
> I am testing the controller to do parallel flow addition/deletions, in
> order to see how fast the controller can add or delete a large number of
> flows. Because in a large network, you may need to add thousands of flows
> and it needs to be done in parallel so that the network can be scalable.
>
> You may be correct in saying that Ryu cannot share the connection to the
> switch among different processes, but the problem right now is that even if
> I just use a single process to add a flow (so no other processes are
> conflicting with it or causing interleaving problems), the OFPT_FLOW_MOD
> message didn't send according to the Wireshark capture.
>
>
> On Mon, Apr 24, 2017 at 8:12 PM, William Fisher <william.w.fisher@
> gmail.com> wrote:
>
>> On Mon, Apr 24, 2017 at 3:46 PM, Yiwen Shen <ys2...@columbia.edu> wrote:
>> >
>> > If I just do add_flow(..) by itself the flows will get added properly
>> onto the switch, but if I do multiprocessing it doesn't appear. However,
>> multiprocessing is the only way I know to do this stuff in parallel. (I've
>> tried multithreading, and the flows do get added but because of GIL, it
>> isn't truly happening in parallel).
>> >
>>
>> What are you ultimately testing, the controller or the switch? If you
>> are optimizing, what is the performance benchmark you are trying to reach?
>>
>> If you are testing the ability of a switch to process multiple
>> simultaneous OpenFlow messages, you should use two separate connections to
>> the switch. Perhaps by running two ryu processes listening on different
>> ports.
>>
>> If you are testing the controller, be aware that ryu has one connection
>> to the switch and isn't designed to share it between processes. (Even if it
>> is possible to share the connection, you may still run into atomicity
>> issues where openflow message bytes get interleaved.) If you tried
>> multithreading in a single process and that worked for you, that's probably
>> the best you can expect.
>>
>>
>
>
> --
> *Yiwen Shen*
> PhD Candidate at Lightwave Research Laboratory
> <http://lightwave.ee.columbia.edu/>
> ------------------------------------------------------------
> ------------------
> 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
>
>
>
--
*Yiwen Shen*
PhD Candidate at Lightwave Research Laboratory
<http://lightwave.ee.columbia.edu/>
------------------------------------------------------------------------------
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
