On 2017/1/7 17:14, Dong Jun wrote:
I tested my issue(https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326936.html)
withpatch serial v3 1-4 (http://patchwork.ozlabs.org/patch/712028/).
It sounds a little vague, i mean all four patches from 1/4 to 4/4.

The issue has been resolved. Gateway NAT and floating ip NAT both worked well and conntrack
flows were completed as well.
Thank you.


On 2017/1/6 20:24, Numan Siddique wrote:


On Fri, Jan 6, 2017 at 9:52 AM, Ben Pfaff <b...@ovn.org <mailto:b...@ovn.org>> wrote:

    On Thu, Jan 05, 2017 at 05:54:46PM -0800, Jarno Rajahalme wrote:
    >
    > > On Jan 5, 2017, at 4:28 PM, Ben Pfaff <b...@ovn.org
    <mailto:b...@ovn.org>> wrote:
    > >
    > > On Tue, Jan 03, 2017 at 02:55:19AM -0800, Mickey Spiegel wrote:
    > >> One of the motivations for clone is to use it as a
    lightweight way to
    > >> resubmit to an earlier table at the beginning of the
    pipeline, without
    > >> incurring all of the overhead associated with openflow patch
    ports.
    > >> One such usage is in OVN, where a recent patch set replaced the
    > >> use of openflow patch ports with clone, for OVN patch ports
    within
    > >> the same bridge (br-int).
    > >>
    > >> Over the holidays, some issues arose related to this usage of
    clone
> >> (see the thread ovn ping from VM to external gateway IP failed).
    > >
    > > Thanks for bringing this up.  I had overlooked these questions
    and this
    > > issue.
    > >
> > I guess that we should save and restore this since we're saving and
    > > restoring the conntrack metadata.  I've written up a patch.
    > >
    > >>   ctx->was_mpls
    > >
    > > I do not think that that this is a correctness issue, but it's
    a nice
    > > optimization to save and restore this.  I've written up a patch.
    >
    > I think the rationale is that ‘was_mpls’ is used to track the
    validity
> of the flow key across an MPLS POP operation. Since the flow key is
    > saved and restored, we should save and restore ‘was_mpls’ as well.

    OK.  I did send a patch that adds that.  Do you want to make a
    suggestion for the commit message?  I may not fully understand the
    issue
    yet, so I don't think the commit message is very good.

    Here's the patch:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html
<https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327207.html>

    > >>   ctx->xin->tables_version (not an issue if bridge does not
    change)
    > >
    > > clone doesn't change the bridge, so this shouldn't matter.
    > >
    > >>   ctx->stack
    > >>   ctx->action_set
    > >
    > > I think it's cleanest if a clone starts off with both of these
    empty and
    > > saves and restores them.  I've written up a patch.
    >
    > I think saving and restoring is needed, but I’m not so sure of
    > clearing these. However, it seems that there is no way for the
    action
> set to be executed within the clone, so I guess it does not matter.

    I guess that it would also be a clean design, and consistent with
    my new
    ct_clear action, to not clear them but instead to start from a
    copy and
    allow for clearing them explicitly within the clone.

    There is already an instruction to clear the action set, so we
    wouldn't
    need to add anything.  I think that the action set can only affect
    what
    happens inside the clone in terms of matches or actions based on the
    actset_output field, though.

    I'm not sure of the value of an action to clear the stack, so I'd be
    inclined to hold off on that until we think of one.

    I'll revise my patch to work this way.

> It would be good to add these changes to the documentation as well.

    My patch does update the documentation on this point.


​Thanks Ben for all the fixes. We are in middle of performance testing with the version of ovn-controller which creates patch ports for router ports.

Once this is done, we will be able to test with the patches you have proposed.

​Dong Jun- May be if you want to test these patches and I see if it resolves the issues which you had posted.
​

Thanks
Numan


    _______________________________________________
    dev mailing list
    d...@openvswitch.org <mailto:d...@openvswitch.org>
    https://mail.openvswitch.org/mailman/listinfo/ovs-dev
<https://mail.openvswitch.org/mailman/listinfo/ovs-dev>



_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to