It seems to me like a bad idea, in general, to use round robin load balancing to send packets to controllers because that is likely to reorder packets. I think that it would probably be a better idea to balance packets across controllers on a flow-by-flow basis. I think that you could use an OpenFlow "select" group for that, by using a bucket for each controller. That would not require any change to OVS.
On Sun, Nov 19, 2017 at 01:47:01PM -0800, Brian Perry wrote: > Summary: OvS last commit 52f793b > I am trying to modify the switch's code to use a round robin scheduler for > sending asynchronous messages (especially PACKET_IN messages) to one of the > controllers within a multiple controller SDN setup. After traversing the > code I think I found where I need to insert this round robin scheduler, > line 4766 and 6225 of ofproto-dpif-xlate.c. > > I plan on modifying this part of the code and testing it to see if I was > correct but it would be great to have some feedback from the community on > this. > 1) Am I on the right path, do I only need to modify the code around line > 4766? Or do I need to modify another part of the code? > 2) What is OFPACT_CONTROLLER case for? From what I can gather macro > OFPACT_FOR_EACH uses a macro that goes through a list that deal with table > entry actions but it could call the execute_controller_action() function > and I don't know why it would. > 3) What does emit_continuation() function do? It looked like it had to do > with table lookups instead of sending asynchronous messages to the > controller. If it only does table lookups why would it call the > execute_controller_action() function. > > > Details: > I setup a simple Mininet topology with a single switch, 3 user computers, > and 2 controllers, where everything is connected to the switch. Currently > when the switch receives a packet with no corresponding forwarding rule it > sends a request to both controllers. I would like it so that it sends the > forwarding rule request in a round robin method. So the first forwarding > rule request will be sent to only controller 1, then the next forwarding > rule request will be sent to only controller 2, then the next one to only > controller 1, then the next one only to controller 2, etc. > > Along side other documents I've read a description of the Open vSwitch > architecture (https://www.slideshare.net/rajdeep/openvswitch-deep-dive) and > pages 25-28 of Pavel's master thesis (https://mail.openvswitch.org/ > pipermail/ovs-discuss/2017-February/043763.html) to get a better > understanding of the internals of OvS. This information paired with the > following post (https://mail.openvswitch.org/pipermail/ovs-discuss/2016- > March/040236.html) informed me that the source code I am looking for is > used within the Userspace and located within the ofproto directory. I > started looking in the ofproto directory for the handle_openflow() > function. This eventually lead me to look at the structure and usage of > ofconn which lead me to line 1741 of connmgr.c where I found the structure > ofproto_async_msg and function connmgr_send_async_msg. After following the > function I noticed that ofproto_async_msg.controller_id is assigned in only > 2 different places; within the execute_controller_action() and > emit_continuation() functions. I continued following the > execute_controller_action() function and noticed that it's called in only 5 > different locations all within the file ofproto-dpif-xlate.c. Within those > 5 locations only lines 4766 and 6225 use some sort of loop to craft and > send asynchronous messages to multiple controllers. > > So my questions become: > 1) Am I on the right path, do I only need to modify the code around line > 4766? Or do I need to modify another part of the code? > 2) What is OFPACT_CONTROLLER case for? From what I can gather macro > OFPACT_FOR_EACH uses a macro that goes through a list that deal with table > entry actions but it could call the execute_controller_action() function > and I don't know why it would. > 3) What does emit_continuation() function do? It looked like it had to do > with table lookups instead of sending asynchronous messages to the > controller. If it only does table lookups why would it call the > execute_controller_action() function. > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
