From 6241bbf69c3b3b31698b34ae5c967ceaecd2c3d7 Mon Sep 17 00:00:00 2001 From: Stephen Sun <5379172+stephenxs@users.noreply.github.com> Date: Wed, 30 Mar 2022 15:06:38 +0800 Subject: [PATCH] Remove redundant and problematic code to skip "pool" field in buffer profile handling (#2197) - What I did Remove redundant and problematic code to skip "pool" field in buffer profile handling - Why I did it When a buffer profile is modified, the snippet of code skipped "pool" field handling without pool's name being parsed, which broke the dependency tracing logic. In a rare scenario, if buffer orchagent receives a notification to remove the pool before removing the profile, it can cause the buffer pool to be removed when it is still referenced. - How I verified it Manually and regression test. Signed-off-by: Stephen Sun --- orchagent/bufferorch.cpp | 7 ------- 1 file changed, 7 deletions(-) diff --git a/orchagent/bufferorch.cpp b/orchagent/bufferorch.cpp index 41101480d590..56f02b2b52f4 100644 --- a/orchagent/bufferorch.cpp +++ b/orchagent/bufferorch.cpp @@ -661,13 +661,6 @@ task_process_status BufferOrch::processBufferProfile(KeyOpFieldsValuesTuple &tup sai_attribute_t attr; if (field == buffer_pool_field_name) { - if (SAI_NULL_OBJECT_ID != sai_object) - { - // We should skip the profile's pool name because it's create only when setting a profile's attribute. - SWSS_LOG_INFO("Skip setting buffer profile's pool %s for profile %s", value.c_str(), object_name.c_str()); - continue; - } - sai_object_id_t sai_pool; ref_resolve_status resolve_result = resolveFieldRefValue(m_buffer_type_maps, buffer_pool_field_name, buffer_to_ref_table_map.at(buffer_pool_field_name),