[ovs-discuss] ovn: OF rules for datapath not getting removed upon ls-del

Flavio Fernandes flavio at flaviof.com
Tue Aug 23 02:01:39 UTC 2016


> On Aug 22, 2016, at 4:32 PM, Flavio Fernandes <flavio at flaviof.com> wrote:
> 
> [cc: Numan and Guru, Ben, Ryan]
> 
> Hi folks,
> 
> I've been chasing an issue in that OF rules are not properly cleaned up when I remove the datapath that is
> associated with a logical switch. The smallest/dumb test I could come up with looks like this:
> 


It occurred to me that I may have done a really lousy job in demonstrating the issue, due to the
confusing output. Sorry about that!

Instead of getting confused, please consider the following unit test in order to reproduce this:

    http://openvswitch.org/pipermail/dev/2016-August/078431.html <http://openvswitch.org/pipermail/dev/2016-August/078431.html>

Thanks,

-- flavio



> 1) start OVS sandbox  (cd ./utilities && rm -rf ./sandbox && ./ovs-sim)
> 2) ovn_start, net_add ... create hv1
> 3) as hv1, create ovs port to be bound to lsp 'foo'
> 4) ls-add sw0
> 5) lsp-add port 'foo'
> 6) undo 3 (ovs port create)
> 7) undo 5 (lsp create)
> 8) undo 4 (ls create)
> 9) look at output of "OF flows" and verify that there is no mentioning of metadata=0x1 anywhere
> 
> The exact test steps are here [testSteps].
> 
> For the output of a 'good' run, look here [goodRun].
> For the output of a 'bad' run, look here [badRun].
> 
> Using git bisect, I determined that the issue was very likely introduced here [issueStart].
> 
> All in all, I would very much appreciate if:
> 
> 1) any of you guys "see" the same, and agree this is an issue;
> 2) know if the changes for "reset flow processing" could be improved so these rules stop 'leaking'.
> 
> I suspect there may be other issues, but I figure we start here and work our way up to the
> commits in 2.6.
> 
> Thank you!
> 
> -- flaviof
> 
> 
> [testSteps]:   https://gist.github.com/de0bf9e1211267f1afd547aad6072c69 <https://gist.github.com/de0bf9e1211267f1afd547aad6072c69>
> [goodRun]: https://gist.github.com/0afeac5b75a0ef6bf015d6868a12a3cd <https://gist.github.com/0afeac5b75a0ef6bf015d6868a12a3cd>
> [badRun]: https://gist.github.com/67cfca69abf8ccba1c57b4a5ff08a94e <https://gist.github.com/67cfca69abf8ccba1c57b4a5ff08a94e>
> 
> 
> [issueStart]:
> f5792c3f36dee70f5c17d03982dce212847024b3 is the first bad commit
> commit f5792c3f36dee70f5c17d03982dce212847024b3
> Author: Numan Siddique <nusiddiq at redhat.com <mailto:nusiddiq at redhat.com>>
> Date:   Thu Aug 11 17:51:39 2016 +0530
> 
>     ovn-controller: Reset flow processing after (re)connection to switch
> 
>     When ovn-controller reconnects to the ovs-vswitchd, it deletes all the
>     OF flows in the switch. It doesn't install the flows again, leaving
>     the datapath broken unless ovn-controller is restarted or ovn-northd
>     updates the SB DB.
> 
>     The reason for this is
>       - lflow_reset_processing() is not called after the reconnection
>       - the hmap "installed_flows" is not cleared, because of which
>         ofctrl_put skips adding the flows to the switch.
> 
>     This patch fixes the issue and also adds a test case to test
>     this scenario.
> 
>     Signed-off-by: Numan Siddique <nusiddiq at redhat.com <mailto:nusiddiq at redhat.com>>
>     Signed-off-by: Ben Pfaff <blp at ovn.org <mailto:blp at ovn.org>>
>     Acked-by: Ryan Moats <rmoats at us.ibm.com <mailto:rmoats at us.ibm.com>>
> 
> :040000 040000 3687d0bb43c69133c7709f6b22315060354c7253 d5da3e29f654a92acf58fcd215366b5aeb53aef6 M     	ovn
> :040000 040000 caf406231eba7541aab62c6bda301f22256e7c76 18f08e67bb4087ea6d05f59356802ef75bc0de81 M     	tests
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160822/434d5f48/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160822/434d5f48/attachment-0002.sig>


More information about the discuss mailing list