[ovs-dev] Openflow 1.4: Eviction mechanism implementation

Ben Pfaff blp at nicira.com
Mon Aug 11 17:16:01 UTC 2014


On Fri, Aug 08, 2014 at 05:39:26PM +0530, Shashwat Srivastava wrote:
> I want to incorporate "Eviction mechanism" as per the openflow 
> specification 1.4
> 
> As per the openflow specification 1.4 (Section 7.3.4.1), there are three 
> eviction flags: importance,lifetime and other. If importance flag is the 
> only flag set (lifetime and others not set), eviction is performed 
> strictly in order of importance field specified in flow entry, that is 
> flow entry with lower importance will be evicted before flow entry with 
> higher importance. 
> 
> But if all flow entries are of same importance, it has been specified that 
> "the eviction mechanism is switch defined ", therefore it is not possible 
> to predict in which order flow entries of same importance will get 
> evicted.
> At present (without implementation of eviction), when a flow table is 
> full, new flow entries are not inserted in the flow table and an error is 
> returned to the controller, controller needs time to work on flow table 
> and thus may cause a disruption of service. Does this means that, users 
> should therefore take care to use importance field wisely to ensure the 
> behaviour they expect and avoid disruption of service. It would be great 
> help if someone could explain how eviction will be done in this case.
> 
> Also kindly suggest action when both the flags for importance and lifetime 
> are simultaneously set, as this is missing in the openflow specification 
> 1.4 

Open vSwitch already implements eviction that can be configured to
meet the requirements of "other" and "lifetime" based eviction.  I
believe that all that we would have to do to comply with OpenFlow 1.4
in this area is to make the feature configurable via the OpenFlow 1.4
table_mod message.

OpenFlow 1.4 does not appear to define how "importance" interacts with
the "lifetime" and "other" eviction policies.  If we implement
importance-based eviction, we will have to decide what would be most
useful for our users.



More information about the dev mailing list