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
