Bug 1589058
Summary: | [OVN] The mac table size of ovn (br-int, br-*) is too small by default and eventually makes openvswitch explode | |||
---|---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Miguel Angel Ajo <majopela> | |
Component: | openvswitch | Assignee: | Eelco Chaudron <echaudro> | |
Status: | CLOSED NOTABUG | QA Contact: | Ofer Blaut <oblaut> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 13.0 (Queens) | CC: | apevec, atelang, bhaley, bjarolim, chrisw, cshastri, dvd, echaudro, erkki.peura, feimingyun, gkumar, jbenc, jlibosva, jraju, jsitnick, kiyyappa, majopela, mcroce, mori, oblaut, ovs-team, pabeni, pablo.iranzo, pmorey, rcernin, rhos-maint, rkhan, sbandyop, srevivo, vkommadi | |
Target Milestone: | zstream | Keywords: | Triaged, ZStream | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | 1558336 | |||
: | 1592333 (view as bug list) | Environment: | ||
Last Closed: | 2018-06-18 13:23:54 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1592333 |
Description
Miguel Angel Ajo
2018-06-08 09:41:54 UTC
(In reply to Miguel Angel Ajo from comment #0) > Another option could be, if we can detect the overflows of such table, have > some mechanism to dynamically increase the size. That'd be of course better. That's not really needed: the hash table that contains the MAC table entries is not allocated for the full specified size. Instead, it is dynamically enlarged (doubled) each time it gets too full, and there's code evicting entries over mac-table-size. The hash table is never shrunk, though (not even when mac-table-size is lowered). In theory, we could increase the default MAC size, but we need to understand the additional impact on this and reach upstream agreement on changing a default. Alternatively, a couple of BZs exists, 1589031 is one of them, they try to solve this in OSP. Which is probably a better solution as this is the OVS use case that needs a bigger table. And the configuration option to change the size exists. It looks odd to change the default MAC table size based on a specific use case. I opened this BZ in relation to OVN, not just for OVS by itself. I'm not sure if this setting has an impact on OVN itself since it does not use NORMAL rules. (In reply to Eelco Chaudron from comment #3) > In theory, we could increase the default MAC size, but we need to understand > the additional impact on this and reach upstream agreement on changing a > default. We had a short discussion with Miguel, Numan and Russell. Let me try to sum it up. On br-int we are not using NORMAL rules, so technically OVN is not affected by this limit. The rest of non-OVN managed bridges might be affected by it, i.e. the provider bridges. Depending on what is the impact of increasing the default size on resource consumption (memory, CPU) it would be good to at least consider if 2048 is still a sane default for deployments that use OVS nowadays. That is to say, if it is cheap to have a bigger MAC learning table, then it would be one less knob that has be adjusted by LPs. (In reply to Jakub Sitnicki from comment #5) > (In reply to Eelco Chaudron from comment #3) > > In theory, we could increase the default MAC size, but we need to understand > > the additional impact on this and reach upstream agreement on changing a > > default. > > We had a short discussion with Miguel, Numan and Russell. Let me try to sum > it up. > > On br-int we are not using NORMAL rules, so technically OVN is not affected > by this limit. The rest of non-OVN managed bridges might be affected by it, > i.e. the provider bridges. > > Depending on what is the impact of increasing the default size on resource > consumption (memory, CPU) it would be good to at least consider if 2048 is > still a sane default for deployments that use OVS nowadays. > > That is to say, if it is cheap to have a bigger MAC learning table, then it > would be one less knob that has be adjusted by LPs. Ok, if OVN does not care about this, I'll close this BZ, and the increase of the MAC table is tracked under BZ 1558336. |