[ovs-discuss] OVS porting design question

[Ben Pfaff]

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.