Thank you! Yimin
On Tue, May 8, 2012 at 9:29 AM, Jesse Gross <je...@nicira.com> wrote: > datapath/vport-gre.c > > On Mon, May 7, 2012 at 6:21 PM, YIMIN CHEN <ymchen.n...@gmail.com> wrote: >> Hi Ben, >> >> Thank you for your reply! I am newbie to openflow development, please >> pardon me if my problem description is not precise :) >> >> Could you please point me to the gre tunnel processing file, I would >> like to take a look to understand it better. >> >> >> Thanks! >> Yimin >> >> On Tue, May 8, 2012 at 12:16 AM, Ben Pfaff <b...@nicira.com> wrote: >>> With the normal way that gre tunnel processing works, you only get a >>> shot at it after decap. >>> >>> Or maybe you're just describing the way that GRE tunnel processing >>> works and don't need resubmit at all. It's hard to tell, since you >>> keep changing your description and your requirements. >>> >>> On Mon, May 07, 2012 at 08:55:36AM +0800, YIMIN CHEN wrote: >>>> I didn't quite yet understand why resubmit does not work for my case. >>>> It could be the same flow table, I just need to search it twice: >>>> -- once before decap, when hit, knows the flow needs to be decap'ed >>>> and resubmitted to the table again >>>> -- once after decap, with the destination IP of decap'ed packet. >>>> >>>> This does not work? >>>> >>>> >>>> Thanks! >>>> >>>> On Sat, May 5, 2012 at 3:40 AM, Ben Pfaff <b...@nicira.com> wrote: >>>> > 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev