[fdborch] Fix FDB flush issues

[liron-ze]

What I did
Add a reference count to ensure that the FDB is not added or deleted during FDB flush.

Why I did it
In the mclag scenario, restart one of a pair of leaf switches. After completing the information exchange between leaf switches, the leaf switch will flush the fdb and then add the fdb, and then if the downlink port down, the fdb will be redirected.
At this point, a bug may appear:

ERR swss#orchagent: :- meta_sai_validate_fdb_entry: object key SAI_OBJECT_TYPE_FDB_ENTRY:{"bvid":"oid:0x26000000000943","mac":"B4:56:B9:F0:00:3E","switch_id":"oid:0x21000000000000"} already exists
ERR swss#orchagent: :- addFdbEntry: Failed to create dynamic FDB b4:56:b9:f0:00:3e on Ethernet16, rv:-6

analysis：
flush fdb, there are three steps

1. Call ASI api after fdborch is processed; sairedis deletes the local cache; deletes fdb in the chip
2. After deleting fdb in the chip, a flush notification will be sent to sairedis, and the fdb entry in ASIC_DB will be deleted
3. When fdborch receives the notification, the fdb cached in orch is deleted

If between step 1 and step 3, fdborch processes the event of adding fdb, it may cause the fdb cache in sairedis to be incorrect or the entries in ASIC_DB are incorrect.
In this way, subsequent additions and deletions will cause larger e exceptions.

How I verified it
flush fdb
add fdb to APPL_DB immediately
set this fdb again after

[prsunny]

request @vasant17 to review

[prsunny]

Please use open/close brace

[vasant17]

I feel you are tracking every flush and incrementing blindly twice (One for dynamic and one for static), before adding back the FDB entry, how are we sure that it will be decremented twice? It wont be the case if the learnt MAC if just dynamic or just dtatic right?

And also, what if the notification is consolidated?

I do see that you have a case where "FDB add" happens between a delete and receiving notification, but this has to be thought through and devise a complete solution.

One potential solution that I can think of is keeping the count based on type of FDB entry (dynamic/static). But that still wont be a complete solution as notification might be consolidated. I think there must be a way to know if a delete notification is pending for an FDB entry in cached in orchangent and while its in ASIC DB, if not we should devise one!

[liron-ze]

For fdb flush, if it is flush all, the bottom layer will send two notifications, dynamic and static, in this case,flush_count+=2;
If you only flush dynamic or static fdb, there will only be one notification, in this case,flush_count++;
E.g:

        attr.id = SAI_FDB_FLUSH_ATTR_ENTRY_TYPE;
        if(data == "dynamic")
        {
            attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_DYNAMIC;
        }
        else if(data == "static")
        {
            attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_STATIC;
        }

Regarding the issue of notification merger, there is an explanation in saifdb.h:

 * Add SAI_FDB_ENTRY_ATTR_TYPE to data.attr list and value set to
 * SAI_FDB_FLUSH_ATTR_ENTRY_TYPE, if SAI_FDB_FLUSH_ATTR_ENTRY_TYPE was not
 * provided to flush API, then 2 notifications will be sent (or 1 notification
 * with 2 data entries) where data.attr will contain SAI_FDB_ENTRY_ATTR_TYPE
 * set accordingly for specific entry types.

But in fdborch, it will still be processed separately:

else if (&consumer == m_fdbNotificationConsumer && op == "fdb_event")
{
    uint32_t count;
    sai_fdb_event_notification_data_t *fdbevent = nullptr;

    sai_deserialize_fdb_event_ntf(data, count, &fdbevent);

    for (uint32_t i = 0; i < count; ++i)
    {
        sai_object_id_t oid = SAI_NULL_OBJECT_ID;

        for (uint32_t j = 0; j < fdbevent[i].attr_count; ++j)
        {
            if (fdbevent[i].attr[j].id == SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID)
            {
                oid = fdbevent[i].attr[j].value.oid;
                break;
            }
        }

        this->update(fdbevent[i].event_type, &fdbevent[i].fdb_entry, oid);
    }

    sai_deserialize_free_fdb_event_ntf(count, fdbevent);

So for every flush notification,flush_count--;

@vasant17

[vasant17]

Can we add a VS test case for this? /Vasant

…

On Oct 25, 2020, at 9:28 PM, liron-ze ***@***.***> wrote:  For fdb flush, if it is flush all, the bottom layer will send two notifications, dynamic and static, in this case,flush_count+=2; If you only flush dynamic or static fdb, there will only be one notification, in this case,flush_count++; E.g: attr.id = SAI_FDB_FLUSH_ATTR_ENTRY_TYPE; if(data == "dynamic") { attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_DYNAMIC; } else if(data == "static") { attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_STATIC; } Regarding the issue of notification merger, there is an explanation in saifdb.h: * Add SAI_FDB_ENTRY_ATTR_TYPE to data.attr list and value set to * SAI_FDB_FLUSH_ATTR_ENTRY_TYPE, if SAI_FDB_FLUSH_ATTR_ENTRY_TYPE was not * provided to flush API, then 2 notifications will be sent (or 1 notification * with 2 data entries) where data.attr will contain SAI_FDB_ENTRY_ATTR_TYPE * set accordingly for specific entry types. But in fdborch, it will still be processed separately: else if (&consumer == m_fdbNotificationConsumer && op == "fdb_event") { uint32_t count; sai_fdb_event_notification_data_t *fdbevent = nullptr; sai_deserialize_fdb_event_ntf(data, count, &fdbevent); for (uint32_t i = 0; i < count; ++i) { sai_object_id_t oid = SAI_NULL_OBJECT_ID; for (uint32_t j = 0; j < fdbevent[i].attr_count; ++j) { if (fdbevent[i].attr[j].id == SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID) { oid = fdbevent[i].attr[j].value.oid; break; } } this->update(fdbevent[i].event_type, &fdbevent[i].fdb_entry, oid); } sai_deserialize_free_fdb_event_ntf(count, fdbevent); So for every flush notification,flush_count--; @vasant17 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vasant17]

For fdb flush, if it is flush all, the bottom layer will send two notifications, dynamic and static, in this case,flush_count+=2;
If you only flush dynamic or static fdb, there will only be one notification, in this case,flush_count++;
E.g:

        attr.id = SAI_FDB_FLUSH_ATTR_ENTRY_TYPE;
        if(data == "dynamic")
        {
            attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_DYNAMIC;
        }
        else if(data == "static")
        {
            attr.value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_STATIC;
        }

Regarding the issue of notification merger, there is an explanation in saifdb.h:

 * Add SAI_FDB_ENTRY_ATTR_TYPE to data.attr list and value set to
 * SAI_FDB_FLUSH_ATTR_ENTRY_TYPE, if SAI_FDB_FLUSH_ATTR_ENTRY_TYPE was not
 * provided to flush API, then 2 notifications will be sent (or 1 notification
 * with 2 data entries) where data.attr will contain SAI_FDB_ENTRY_ATTR_TYPE
 * set accordingly for specific entry types.

But in fdborch, it will still be processed separately:

else if (&consumer == m_fdbNotificationConsumer && op == "fdb_event")
{
    uint32_t count;
    sai_fdb_event_notification_data_t *fdbevent = nullptr;

    sai_deserialize_fdb_event_ntf(data, count, &fdbevent);

    for (uint32_t i = 0; i < count; ++i)
    {
        sai_object_id_t oid = SAI_NULL_OBJECT_ID;

        for (uint32_t j = 0; j < fdbevent[i].attr_count; ++j)
        {
            if (fdbevent[i].attr[j].id == SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID)
            {
                oid = fdbevent[i].attr[j].value.oid;
                break;
            }
        }

        this->update(fdbevent[i].event_type, &fdbevent[i].fdb_entry, oid);
    }

    sai_deserialize_free_fdb_event_ntf(count, fdbevent);

So for every flush notification,flush_count--;

@vasant17

@liron-ze Thanks for the exaplanation. But this solution seems very brittle to me. For any reason, if we miss a notification, we will stop adding FB entries, Also, if we receive more than expected number of notification count goes to negative? Can we run this code with different types of flushes (flush by only bridge_port_ID, flush by only BVID, FLUSH all when static and dynamic entries are present). Also can we assert count flush_count never goes negative? Can we add or improve VS test case of this code change?