[ovs-dev] [PATCH v1] doc: Remove experimental tag for SMC cache.
ian.stokes at intel.com
Thu Jul 4 10:39:30 UTC 2019
On 7/4/2019 11:12 AM, Ilya Maximets wrote:
> On 03.07.2019 19:58, Ian Stokes wrote:
>> On 6/27/2019 12:44 PM, Yipeng Wang wrote:
>>> SMC cache was introduced in 2.10 with experimental tag.
>>> SMC cache is a layer of software cache located after EMC
>>> cache. The purpose is to improve the performance of use
>>> cases that many flows missing the EMC cache.
>>> One can enable SMC cache using smc-enable=true option.
>> Thanks for this Yipeng.
>> I'd raised the topic of removing the experimental tag at the community call previously.
>> I guess two aspects were called out that form part of the litmus test for when the tag should be removed.
>> 1. Is the feature in use in common/commercial use?
>> 2. Are there any to-dos or known bugs to be resolved?
>> WRT point 1, I do believe it has been used/tested in commercial deployments and has been benchmarked against realistic deployments with positive results over EMC (except when there is only a small number of flows). I believe this was even presented by Red Hat at the OVS conference last year, so this is encouraging.
>> WRT to known bugs I'm not aware of any outstanding. There have been a handful of patches upstreamed since 2.10 to address some minor issues.
>> I think it's ok to remove this tag for the 2.12 release.
>> Would be interested to hear others thoughts?
> Hi, Ian and Yipeng.
> SMC seems stable enough now. Since fixing one major bug last year I
> didn't noticed about new issues, however I didn't try to use it in
> long-living setups.
> This change doesn't enable SMC by default, so it's totally OK for
> me to remove the experimental tag. This way we'll, probably, have
> more users of this feature and subsequently more testing that will
> allow us to enable it by default for a next releases.
Thanks Ilya, I agree, its seems to be a natural first step before
> So, idea is good. One comment inline for the patch itself. And
> rebase is needed also.
> Best regards, Ilya Maximets.
>>> Signed-off-by: Yipeng Wang <yipeng1.wang at intel.com>
>>> Documentation/topics/dpdk/bridge.rst | 4 ++--
>>> NEWS | 1 +
>>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>> diff --git a/Documentation/topics/dpdk/bridge.rst b/Documentation/topics/dpdk/bridge.rst
>>> index a3ed926..71e1af6 100644
>>> --- a/Documentation/topics/dpdk/bridge.rst
>>> +++ b/Documentation/topics/dpdk/bridge.rst
>>> @@ -117,7 +117,7 @@ It is also possible to enable/disable EMC on per-port basis using::
>>> For more information on the EMC refer to :doc:`/intro/install/dpdk` .
>>> -SMC cache (experimental)
>>> +SMC cache
> Above line should be shortened according to the new section name
> to be rST compliant, otherwise it will trigger a warning/error
> while docs generation.
>>> SMC cache or signature match cache is a new cache level after EMC cache.
>>> @@ -125,7 +125,7 @@ The difference between SMC and EMC is SMC only stores a signature of a flow
>>> thus it is much more memory efficient. With same memory space, EMC can store 8k
>>> flows while SMC can store 1M flows. When traffic flow count is much larger than
>>> EMC size, it is generally beneficial to turn off EMC and turn on SMC. It is
>>> -currently turned off by default and an experimental feature.
>>> +currently turned off by default.
>>> To turn on SMC::
>>> diff --git a/NEWS b/NEWS
>>> index 2f8171f..bf99295 100644
>>> --- a/NEWS
>>> +++ b/NEWS
>>> @@ -29,6 +29,7 @@ Post-v2.11.0
>>> * New action "check_pkt_len".
>>> * Port configuration with "other-config:priority-tags" now has a mode
>>> that retains the 802.1Q header even if VLAN and priority are both zero.
>>> + * Removed experimental tag for SMC cache.
>>> - OVSDB:
>>> * OVSDB clients can now resynchronize with clustered servers much more
>>> quickly after a brief disconnection, saving bandwidth and CPU time.
More information about the dev