I see, thank you.
On Apr 26, 2017 2:35 AM, "Yi Tseng" <a86487...@gmail.com> wrote:
> Hi
>
> For me, I just start multiple Ryu controller with different IP/TCP port
>
> And create connection between controllers(by simple socket)
>
> --
> Yi
>
> 2017-04-25 20:31 GMT-07:00 Yiwen Shen <ys2...@columbia.edu>:
>
>> How do you create multiple instances of the Ryu controller?
>>
>> On Tue, Apr 25, 2017 at 7:57 PM, Yi Tseng <a86487...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> In my opinion, you can create multiple instance of Ryu controller, and
>>> connect switch to all controllers.
>>>
>>> You need to design mechanism for syncing flow data between multiple
>>> controller instances.
>>>
>>>
>>> --Yi
>>>
>>> 2017-04-25 12:54 GMT-07:00 Yiwen Shen <ys2...@columbia.edu>:
>>>
>>>> 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.fis...@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
>>>>
>>>>
>>>
>>>
>>> --
>>> Yi Tseng (a.k.a Takeshi)
>>> Taiwan National Chiao Tung University
>>> Department of Computer Science
>>> W2CNLab
>>>
>>> https://takeshi.tw
>>>
>>
>>
>>
>> --
>> *Yiwen Shen*
>> PhD Candidate at Lightwave Research Laboratory
>> <http://lightwave.ee.columbia.edu/>
>>
>
>
>
> --
> Yi Tseng (a.k.a Takeshi)
> Taiwan National Chiao Tung University
> Department of Computer Science
> W2CNLab
>
> https://takeshi.tw
>
------------------------------------------------------------------------------
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
