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.fis...@gmail.com
> <mailto:william.w.fis...@gmail.com>> wrote:
> On Mon, Apr 24, 2017 at 3:46 PM, Yiwen Shen <ys2...@columbia.edu
> <mailto: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
------------------------------------------------------------------------------
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
