On Tue, Jan 29, 2013 at 10:43:02AM -0500, soaring eagle wrote: > We are considering porting OVS datapath to a new ASIC hardware platform by > writing a provider for the hardware. We have few basic design questions > that we are looking to get some feedback on: > > 1) We are trying to decide whether to implement the provider > rule->construct, destruct routines synchronously or asynchronously. One > hardware flow update generally takes less than 1 ms on single ASIC but can > take several ms if several ASICs have to be updated and some of the ASICs > are not on the same board (stacking/chassis designs) and RPC has to done to > update the remote ASICs. > > With a synchronous rule provider, the concern is that ofproto can get > blocked when the controller is trying to update several hundred flows. This > may cause couple of issues: > > - Controller will get blocked/slow updating the flows on a switch and may > not be able to service flow updates for other switches > - Controller may not be able to send control keepalive packets if it is > implementing a time sensitive protocol and ofproto is serializing all the > operations > > Do you think these are valid concerns? Making the rule routines > asynchronous adds more complexity to the implementation, so we want to make > sure there would be benefits of going the asynchronous path.
It sounds like asynchronous implementation will produce better results, even if it's more work. > b) Assuming we do asynchronous rule operations, what does ofproto do when > a rule construct fails. Does it send asynchronous message to the controller > informing the flow could not be added. We are trying to understand how > would a controller know whether the flow was successfully added or not. It sends an OpenFlow error message to the controller. > c) While a given rule construct operation is in progress asynchronously, > would the ofproto issue new rule construct operations. How many such new > rule construct operations can ofproto issue before it expects an > acknowledgement on a pending operation. There's currently a hard-coded limit of 50 outstanding OpenFlow flow_mod operations at any given time. After that, it waits for a flow_mod to complete before allowing another one to issue. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
