The difference is that Yimin Chen wants to process the packet through two flow tables, one before and one after decap. With the normal way that gre tunnel processing works, you only get a shot at it after decap.
On Fri, May 04, 2012 at 12:35:00PM -0700, Karl Yang wrote: > what is the difference between your this case and the "gre" tunnel > processing case within data path code? > > On Fri, May 4, 2012 at 10:05 AM, Ben Pfaff <b...@nicira.com> wrote: > > > No. > > > > On Fri, May 04, 2012 at 10:16:14AM +0800, YIMIN CHEN wrote: > > > Hi Ben, > > > > > > My goal is to implement a decap action that would decap a packet with > > > external IP addresses, and then have the decapped packet, with > > > internal IP addresses, do a flow lookup again. > > > > > > Can this be achieved using resubmit? > > > > > > Thanks! > > > Yimin > > > > > > On Fri, May 4, 2012 at 9:37 AM, Ben Pfaff <b...@nicira.com> wrote: > > > > You can read PORTING in the root of the tree. > > > > > > > > It would be best if you'd explain your goal first, instead of doing a > > > > deep dive into implementation details. > > > > > > > > On Fri, May 04, 2012 at 09:20:38AM +0800, YIMIN CHEN wrote: > > > >> Hi Ben, > > > >> > > > >> Thank you for the detailed information! I read this part of the code, > > > >> and have some confusion. Can you please review the following to see if > > > >> my understanding of code is correct? > > > >> > > > >> 1) ofproto/ code is userspace code, and datapath/ code is the actual > > dp code. > > > >> 2) ofproto handles the rule insertion from control plane, and datapath > > > >> handles the actual flow lookup. > > > >> 3) resubmit is handled in userspace? I saw the resubmit logic > > > >> xlate_nicira_action() is in ofproto I didn't see find any code in > > > >> datapath that handles resubmit, not even in ovs-ofctl.c. Is > > > >> xlate_nicira_action() doing flow insertion with resubmit action or > > > >> actually performing the dp actions? I am confused. > > > >> > > > >> What is the relationship between ofproto userspace and the dp code? > > > >> what is the difference between xlate table action and odp action? > > > >> > > > >> I think I am very confused, if there is any documentation I can read > > > >> to understand this design better, would you please give me a pointer? > > > >> > > > >> Thanks! > > > >> Yimin > > > >> > > > >> On Thu, May 3, 2012 at 11:30 AM, Ben Pfaff <b...@nicira.com> wrote: > > > >> > It's documented in nicira-ext.h: > > > >> > > > > >> > /* Action structures for NXAST_RESUBMIT and NXAST_RESUBMIT_TABLE. > > > >> > * > > > >> > * These actions search one of the switch's flow tables: > > > >> > * > > > >> > * - For NXAST_RESUBMIT_TABLE only, if the 'table' member is not > > 255, then > > > >> > * it specifies the table to search. > > > >> > * > > > >> > * - Otherwise (for NXAST_RESUBMIT_TABLE with a 'table' of 255, > > or for > > > >> > * NXAST_RESUBMIT regardless of 'table'), it searches the > > current flow > > > >> > * table, that is, the OpenFlow flow table that contains the > > flow from > > > >> > * which this action was obtained. If this action did not > > come from a > > > >> > * flow table (e.g. it came from an OFPT_PACKET_OUT message), > > then table 0 > > > >> > * is the current table. > > > >> > * > > > >> > * The flow table lookup uses a flow that may be slightly modified > > from the > > > >> > * original lookup: > > > >> > * > > > >> > * - For NXAST_RESUBMIT, the 'in_port' member of struct > > nx_action_resubmit > > > >> > * is used as the flow's in_port. > > > >> > * > > > >> > * - For NXAST_RESUBMIT_TABLE, if the 'in_port' member is not > > OFPP_IN_PORT, > > > >> > * then its value is used as the flow's in_port. Otherwise, > > the original > > > >> > * in_port is used. > > > >> > * > > > >> > * - If actions that modify the flow (e.g. OFPAT_SET_VLAN_VID) > > precede the > > > >> > * resubmit action, then the flow is updated with the new > > values. > > > >> > * > > > >> > * Following the lookup, the original in_port is restored. > > > >> > * > > > >> > * If the modified flow matched in the flow table, then the > > corresponding > > > >> > * actions are executed. Afterward, actions following the resubmit > > in the > > > >> > * original set of actions, if any, are executed; any changes made > > to the > > > >> > * packet (e.g. changes to VLAN) by secondary actions persist when > > those > > > >> > * actions are executed, although the original in_port is restored. > > > >> > * > > > >> > * Resubmit actions may be used any number of times within a set of > > actions. > > > >> > * > > > >> > * Resubmit actions may nest to an implementation-defined depth. > > Beyond this > > > >> > * implementation-defined depth, further resubmit actions are > > simply ignored. > > > >> > * > > > >> > * NXAST_RESUBMIT ignores 'table' and 'pad'. NXAST_RESUBMIT_TABLE > > requires > > > >> > * 'pad' to be all-bits-zero. > > > >> > * > > > >> > * Open vSwitch 1.0.1 and earlier did not support recursion. Open > > vSwitch > > > >> > * before 1.2.90 did not support NXAST_RESUBMIT_TABLE. > > > >> > */ > > > >> > struct nx_action_resubmit { > > > >> > ovs_be16 type; /* OFPAT_VENDOR. */ > > > >> > ovs_be16 len; /* Length is 16. */ > > > >> > ovs_be32 vendor; /* NX_VENDOR_ID. */ > > > >> > ovs_be16 subtype; /* NXAST_RESUBMIT. */ > > > >> > ovs_be16 in_port; /* New in_port for checking flow > > table. */ > > > >> > uint8_t table; /* NXAST_RESUBMIT_TABLE: table > > to use. */ > > > >> > uint8_t pad[3]; > > > >> > }; > > > >> > OFP_ASSERT(sizeof(struct nx_action_resubmit) == 16); > > > >> > > > > >> > and in ovs-ofctl(8): > > > >> > > > > >> > resubmit:port > > > >> > resubmit([port],[table]) > > > >> > Re-searches this OpenFlow flow table (or the > > table whose > > > >> > number is specified by table) with the > > in_port field > > > >> > replaced by port (if port is specified) and > > executes the > > > >> > actions found, if any, in addition to any > > other actions > > > >> > in this flow entry. > > > >> > > > > >> > Recursive resubmit actions are obeyed up to an > > implemenā > > > >> > tation-defined maximum depth. Open vSwitch > > 1.0.1 and > > > >> > earlier did not support recursion; Open > > vSwitch before > > > >> > 1.2.90 did not support table. > > > >> > > > > >> > > > > >> > On Thu, May 03, 2012 at 09:54:08AM +0800, YIMIN CHEN wrote: > > > >> >> Hi Ben, > > > >> >> > > > >> >> Thank you for your reply! I saw there is some code about resubmit > > > >> >> Nicira extension action, but that seems to be in userspace > > ofproto.c, > > > >> >> not in datapath, so I didn't know that is related. Could you help > > > >> >> clarify for me how does resubmit work? > > > >> >> > > > >> >> > > > >> >> Thanks! > > > >> >> Yimin > > > >> >> > > > >> >> On Wed, May 2, 2012 at 12:40 PM, Ben Pfaff <b...@nicira.com> wrote: > > > >> >> > On Wed, May 02, 2012 at 10:53:10AM +0800, YIMIN CHEN wrote: > > > >> >> >> I am looking at ovs dp code, and is looking at a correct way > > for a > > > >> >> >> flow to traverse the table twice. The goal is like this: > > > >> >> >> > > > >> >> >> flow lookup => tbl_lookup() > > > >> >> >> perform actions => execute_actions() which changes the packet > > > >> >> >> flow lookup using the new packet => tbl_lookup() > > > >> >> >> perform actions on the new packet => execute_actions. > > > >> >> > > > > >> >> > Do you want the "resubmit" Nicira extension action? > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev