> lldp: refactor processing all lldp-neighbors

Maybe instead of creating a new hash table for the prune list and accessing it a lot, what if instead NMLldpListenerPrivate had a "guint32 neighbor_stamp;" that starts at zero.

Then each call to process_lldp_neighbors() you increment the neighbor_stamp.  At the beginning of the neighbors loop you "num_to_remove = g_hash_table_size(priv->lldp_neighbors)".  Each time you find a neigh_old (equal or unequal) you decrement that because the neighbor won't be removed or it'll get re-added.  Each time you add or keep a neighbor you increment "num_added" and set the neighbor's stamp to priv->neighbor_stamp.  Then the capacity check becomes "if (num_added - num_to_remove > MAX_NEIGHBORS)".

At the end walk priv->lldp_neighbors and compare each neighbor's stamp against priv->neighbor_stamp and if it is less g_hash_table_iter_remove() that one.

Just a thought; then we only use plain arithmetic, don't allocate a new hash table every time, and don't keep searching the hash.

> lldp: factor our lldp_neighbor_to_variant()

our -> out

> lldp: process one neighbor at a time

Can we get process_lldp_neighbors() to call process_lldp_neighbor()?  They use almost exactly the same code.

(In reply to Dan Williams from comment #1)
> > lldp: refactor processing all lldp-neighbors
>
> Just a thought; then we only use plain arithmetic, don't allocate a new hash
> table every time, and don't keep searching the hash.
> 
> > lldp: process one neighbor at a time
> 
> Can we get process_lldp_neighbors() to call process_lldp_neighbor()?  They
> use almost exactly the same code.

I added another patch "lldp: drop process_lldp_neighbors()" to get rid of process_lldp_neighbors() entirely.


Repushed.

LGTM

merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=d4ca43613eeb0e20c5f9a4369150017ad206587e