| Message ID | 1510353905-1442-1-git-send-email-guru@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev] ovs-ctl: Don't remember vport-* kernel modules | expand |
On Fri, Nov 10, 2017 at 2:45 PM, Gurucharan Shetty <guru@ovn.org> wrote: > From OVS 2.8, ovs-vswitchd, when it starts, will > load the kernel modules for tunnels. It has logic > inside it to choose either upstream kernel module > or vport-* kernel module. > > So, when we run 'force-reload-kmod' to upgrade to > OVS 2.8 from a previous version, we do not need to > remember the vport-* kernel module that was previously > loaded. It is not really harmful to load vport-* kernel > module though. > > On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel > module for tunnels. > > But, on RHEL 7.x we have hit a bug caused by iptables > startup script which tries to remove all kernel modules > related to linux conntrack. It fails to unload openvswitch > kernel module because it has a reference count on it. But it > succeeds in unloading vport-geneve and in turn the upstream > "geneve" kernel module. This causes the tunnels to go down. > > With this patch, we avoid the above situation, by not loading > vport-geneve kernel module. ovs-vswitchd when it starts will > load upstream geneve. And when "iptables stop" runs, since > "geneve" has nothing to do with conntrack, it spares it. > Ideally, we should fix this by incrementing the refcount > on the kernel modules. > > Signed-off-by: Gurucharan Shetty <guru@ovn.org> > --- Looks good to me. Acked-by: William Tu <u9012063@gmail.com>
On 13 November 2017 at 06:43, William Tu <u9012063@gmail.com> wrote: > On Fri, Nov 10, 2017 at 2:45 PM, Gurucharan Shetty <guru@ovn.org> wrote: > > From OVS 2.8, ovs-vswitchd, when it starts, will > > load the kernel modules for tunnels. It has logic > > inside it to choose either upstream kernel module > > or vport-* kernel module. > > > > So, when we run 'force-reload-kmod' to upgrade to > > OVS 2.8 from a previous version, we do not need to > > remember the vport-* kernel module that was previously > > loaded. It is not really harmful to load vport-* kernel > > module though. > > > > On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel > > module for tunnels. > > > > But, on RHEL 7.x we have hit a bug caused by iptables > > startup script which tries to remove all kernel modules > > related to linux conntrack. It fails to unload openvswitch > > kernel module because it has a reference count on it. But it > > succeeds in unloading vport-geneve and in turn the upstream > > "geneve" kernel module. This causes the tunnels to go down. > > > > With this patch, we avoid the above situation, by not loading > > vport-geneve kernel module. ovs-vswitchd when it starts will > > load upstream geneve. And when "iptables stop" runs, since > > "geneve" has nothing to do with conntrack, it spares it. > > Ideally, we should fix this by incrementing the refcount > > on the kernel modules. > > > > Signed-off-by: Gurucharan Shetty <guru@ovn.org> > > --- > Looks good to me. > > Acked-by: William Tu <u9012063@gmail.com> > Thanks William. I applied this to master and 2.8
On Fri, Nov 10, 2017 at 02:45:05PM -0800, Gurucharan Shetty wrote: > From OVS 2.8, ovs-vswitchd, when it starts, will > load the kernel modules for tunnels. It has logic > inside it to choose either upstream kernel module > or vport-* kernel module. > > So, when we run 'force-reload-kmod' to upgrade to > OVS 2.8 from a previous version, we do not need to > remember the vport-* kernel module that was previously > loaded. It is not really harmful to load vport-* kernel > module though. > > On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel > module for tunnels. > > But, on RHEL 7.x we have hit a bug caused by iptables > startup script which tries to remove all kernel modules > related to linux conntrack. It fails to unload openvswitch > kernel module because it has a reference count on it. But it > succeeds in unloading vport-geneve and in turn the upstream > "geneve" kernel module. This causes the tunnels to go down. > > With this patch, we avoid the above situation, by not loading > vport-geneve kernel module. ovs-vswitchd when it starts will > load upstream geneve. And when "iptables stop" runs, since > "geneve" has nothing to do with conntrack, it spares it. > Ideally, we should fix this by incrementing the refcount > on the kernel modules. > > Signed-off-by: Gurucharan Shetty <guru@ovn.org> Hi Guru, Sorry for the delayed response. I missed this before I went on holiday. > --- > utilities/ovs-ctl.in | 11 ----------- > 1 file changed, 11 deletions(-) > > diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in > index 2e1209a..f1b01d1 100755 > --- a/utilities/ovs-ctl.in > +++ b/utilities/ovs-ctl.in > @@ -30,17 +30,9 @@ done > ## start ## > ## ----- ## > > -# Keep track of removed vports so we can reload them if needed > -removed_vports="" > - > insert_mods () { > # Try loading openvswitch again. > action "Inserting openvswitch module" modprobe openvswitch > - > - for vport in $removed_vports; do > - # Don't treat failures to load vports as fatal error > - action "Inserting $vport module" modprobe $vport || true > - done > } Does this break things if we can't use the in kernel tunnels? Have you tried this on an < 4.3 kernel? In that case we should have to use the compat/vport interface. > > insert_mod_if_required () { > @@ -398,9 +390,6 @@ force_reload_kmod () { > > for vport in `awk '/^vport_/ { print $1 }' /proc/modules`; do > action "Removing $vport module" rmmod $vport > - if ! grep -q $vport /proc/modules; then > - removed_vports="$removed_vports $vport" > - fi > done > > if test -e /sys/module/openvswitch; then > -- > 2.7.4 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in index 2e1209a..f1b01d1 100755 --- a/utilities/ovs-ctl.in +++ b/utilities/ovs-ctl.in @@ -30,17 +30,9 @@ done ## start ## ## ----- ## -# Keep track of removed vports so we can reload them if needed -removed_vports="" - insert_mods () { # Try loading openvswitch again. action "Inserting openvswitch module" modprobe openvswitch - - for vport in $removed_vports; do - # Don't treat failures to load vports as fatal error - action "Inserting $vport module" modprobe $vport || true - done } insert_mod_if_required () { @@ -398,9 +390,6 @@ force_reload_kmod () { for vport in `awk '/^vport_/ { print $1 }' /proc/modules`; do action "Removing $vport module" rmmod $vport - if ! grep -q $vport /proc/modules; then - removed_vports="$removed_vports $vport" - fi done if test -e /sys/module/openvswitch; then
From OVS 2.8, ovs-vswitchd, when it starts, will load the kernel modules for tunnels. It has logic inside it to choose either upstream kernel module or vport-* kernel module. So, when we run 'force-reload-kmod' to upgrade to OVS 2.8 from a previous version, we do not need to remember the vport-* kernel module that was previously loaded. It is not really harmful to load vport-* kernel module though. On RHEL7.x and OVS 2.8, we use the upstream "geneve" kernel module for tunnels. But, on RHEL 7.x we have hit a bug caused by iptables startup script which tries to remove all kernel modules related to linux conntrack. It fails to unload openvswitch kernel module because it has a reference count on it. But it succeeds in unloading vport-geneve and in turn the upstream "geneve" kernel module. This causes the tunnels to go down. With this patch, we avoid the above situation, by not loading vport-geneve kernel module. ovs-vswitchd when it starts will load upstream geneve. And when "iptables stop" runs, since "geneve" has nothing to do with conntrack, it spares it. Ideally, we should fix this by incrementing the refcount on the kernel modules. Signed-off-by: Gurucharan Shetty <guru@ovn.org> --- utilities/ovs-ctl.in | 11 ----------- 1 file changed, 11 deletions(-)