summaryrefslogtreecommitdiff
path: root/lib/json.h
diff options
context:
space:
mode:
authorAmeya Dharkar <adharkar@vmware.com>2020-04-10 17:59:31 -0700
committerAmeya Dharkar <adharkar@vmware.com>2020-04-10 17:59:31 -0700
commit44f7f1320cd2fcb369aa9631b01832dba2ef68c2 (patch)
tree7903f12ec51aa8824c2eaf7ceb8eeb0dde23ae90 /lib/json.h
parenteb728e0746f241cbf95116485090eea741e632a3 (diff)
zebra: Address sequencing issue while sending RMAC via FPM
Issue: For consecutive messages such as MAC1 -> VTEP1 add MAC1 -> VTEP2 add MAC1 -> VTEP1 add Final state, i.e. (MAC1 -> VTEP1 add) should be sent via FPM. But, with current code, FPM will send (MAC1 -> VTEP2 add) RCA: When FPM receives (MAC1, VTEP1), it stores it in the FPM processing queue and hash table. When FPM receives (MAC1, VTEP2), this entry is stored as another node as hash table key is (mac, vtep and vni) IF FPM again receives (MAC1, VTEP1), we fetch this node in the hash table which is already enqueued. When the FPM queue is processed, we will send FPM message for (MAC1, VTEP1) first and then for (MAC1, VTEP2) This sequencing issue happened because the key of the table is (MAC, VTEP, VNI) Fix: Change the key of the hash table to (MAC, VNI) So, every time we receive a new update for (MAC1, VNI1), we will find a node in the processing queue corresponding to MAC1 if present. We will update this same node for every operation related to (MAC1, VNI1) Thus, at the time when FPM processes this node, it will have latest MAC1 info. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Diffstat (limited to 'lib/json.h')
0 files changed, 0 insertions, 0 deletions