[ovs-dev] [PATCH v1] doc: Remove experimental tag for SMC cache.

Ian Stokes 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 
replacing EMC.

> So, idea is good. One comment inline for the patch itself. And
> rebase is needed also.
> 
> Best regards, Ilya Maximets.
> 
>>
>> Regards
>> Ian
>>
>>> 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.

+1

Regards
Ian
> 
>>>      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 mailing list