Perhaps once you understand, it will make sense? :) Call it whatever flow_id or cookie or xyz? Let me call it "flow index" for the sake of this discussion. The ovs datapath has some sort of a flow index to look into the flow table when a packet arrives, right? Now, how does the ovs datapath arrive at this flow index (upon a packet arrival)? It takes certain match parameters (from the packet header and perhaps some metadata) and hashes them, right?
I am requesting for an API, where these match parameters are provided in the API message (I think I called it of ofp_type OFPT_GET_FLOWID_REQUEST - let me call it OFPT_GET_FLOW_INDEX_REQ), and used to compute the hash (as done with fields from packet header+metadata)... Why is this API needed? Let's consider this use case: 1. I have a Firewall app running on top of openvswitch. 2. A north-bound user of this Firewall configures policies and rules into the Firewall. 3. Consider a rule from a north-bound user coming down to the Firewall. 4. The Firewall needs to save this rule somewhere in its database... Agree? Two options to do this: 1. It takes a bunch of parameters (e.g. 5 tuple) from the user rule and hashes and computes an index into its policy-rule-database where it can save the rule. 2. Alternatively, it asks the ovs datapath (using the new API I am asking for) to get a flow index. It then uses this flow index to save the rule (from the north-bound) user into its policy-rule-database. 5. Now let's say a packet arrives (into openvswitch datapath). What does the datapath do? It hashes on certain packet fields and computes a flow index and checks the corresponding entry in the flow table... right? Let's say this is a new flow. What does the datapath do? Let's say it sends the packet (along with the flow index) to the controller (in my case the Firewall). 6. So now the Firewall gets the packet and has to decide whether to permit or deny this flow... With me so far? 7. How does the Firewall do that? It has to look into its policy-rule-database and locate a matching rule... 8. How does the Firewall locate the matching rule? One option is to hash on fields from the packet to compute an index (see step 4 above). The second option (where the API I am requesting comes in handy) is to use the ovs datapath flow index itself (see step 4, option (2)). With the second option, the Firewall can locate the matching rule simply by using the flow index that comes to it along with the packet. I hope this is clear now. Please please let me know if it is not clear... or if I misunderstood how the ovs datapath works... Thanks, Ashok On Tue, Jan 6, 2015 at 8:52 AM, Ben Pfaff <[email protected]> wrote: > On Mon, Jan 05, 2015 at 11:24:26PM -0800, Ashok Chippa wrote: > > Could someone please let me know if my request can be accomodated... > > > > I have asked a few times for this before, but I'll ask again: > > > > Basically, I need a new ofp_type support... something like > > OFPT_GET_FLOWID_REQUEST and OFPT_GET_FLOWID_RESPONSE. > > > > Looking for an API, that given certain match parameters in an ofp_type > > OFPT_GET_FLOWID_REQUEST message, returns a FLOWID (or cookie)... in the > > OFPT_GET_FLOWID_RESPONSE message. > > > > Basically take that part of the "ovs-ofctl add-flow <bridge-name> > > <flow>"... code that determines the flow_id and use it to implement the > > above API. In this API the flow comes from the OFPT_GET_FLOWID_REQUEST > > instead of the "ovs-ofctl add-flow..." CLI... > > > > Please someone let me know if this can be added.. or if I should add > it... > > If later, could someone kindly guide me to where supoprt for "ovs-ofctl > > add-flow..." resides... > > I've seen your request each time, and still don't understand what you > need or why you need it. It doesn't make any sense. OVS doesn't have > anything called a "flow_id", and so your description that the new request > would generate a flow_id from a flow cannot be implemented. >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
