Summary on issues about PIT-CS

[zjkmxy]

Updated

• Performance is 25-50% worse after putting expiration in the same thread. Maybe the map deletion is slow.
  • Possible bottleneck:

    ndnd/fw/table/pit-cs-tree.go

    Line 358 in 1818c55

    delete(curNode.parent.children, curNode.component.Hash())

  • Should consider pooling it if associated with memory free.
  • And can we get rid of the recursive tree structure?
• PIT tokens are not shown to be used in any tests. Should be fixed now but need verify. Check if any packet going from YaNFD to NFD carrying that token.
• pitTokenMap seems to be wrong:

  ndnd/fw/table/pit-cs-tree.go

  Line 22 in 1818c55

  pitTokenMap map[uint32]*nameTreePitEntry

  • Should be pooled (such as a free list), and the pitToken should be the pool index.

Background:

#38 #40

Old Version

• Performance is 25-50% worse after putting expiration in the same thread. Maybe the map deletion is slow.
  Possible bottleneck: https://github.com/named-data/YaNFD/blob/79b7e56d00715a9dc8f447ba68dfaec5dfc2f155/table/pit-cs-tree.go#L333
  • Should consider pooling it if associated with memory free.
  • And can we get rid of the recursive tree structure?
• Till now PIT tokens are not shown to be used in any tests. Not sure if it is YaNFD's problem.
• pitTokenMap seems to be wrong: https://github.com/named-data/YaNFD/blob/79b7e56d00715a9dc8f447ba68dfaec5dfc2f155/table/pit-cs-tree.go#L25
  • Should be pooled (such as a free list), and the pitToken should be the pool index.
• csMap does not look good. It assumes the hashes have no conflict.
  https://github.com/named-data/YaNFD/blob/79b7e56d00715a9dc8f447ba68dfaec5dfc2f155/table/pit-cs-tree.go#L29
  https://github.com/named-data/YaNFD/blob/79b7e56d00715a9dc8f447ba68dfaec5dfc2f155/table/pit-cs-tree.go#L372

[pulsejet]

csMap does not look good. It assumes the hashes have no conflict.

Just a note as I was reading this - hash conflicts for cache should not be an issue. If the old packet gets dropped.. that's still okay

[pulsejet]

Fixed on main. Turns out it's not the delete that is slow but the gc effects of doing it.