ofed: don't stop removing stale RoCE GIDs at the first hole

[aehrenberg_nvidia.com]

Summary

When cleaning up stale GIDs the scan stopped as soon as
rdma_get_gid_attr() failed. But that can also happen for empty entries
in the middle of the table, so a single gap left everything after it
behind and the GID entries could eventually run out.

Now the whole table is scanned and the empty slots are simply skipped.

[kib]

sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c

216

Why is the value initialized so early?
IMO it should be done right before the loop that uses it.

BTW, what guarantees the stability of the gid table?

[jhb]

sys/ofed/drivers/infiniband/core/ib_roce_gid_mgmt.c

216

I agree with @kib on moving the initialization down to just before the loop. In particular, I believe roce_gid_enum_netdev_default() might grow the table so the length might be stale?

For @kib's second question, I think it's ok if the table is changed concurrently, it might be that we might miss a stale GID if it grows a new stale entry concurrently, but presumably 1) new entries shouldn't be stale and 2) we'd converge eventually.

278

I believe my assumption when I updated this code is that the table wouldn't have holes which is why I had written the loop the way it was. But my asssumption could easily be false in which case I think this is fine once you move the initialization down to just before the loop starts.

[aehrenberg_nvidia.com]

Per kib and jhb comments, gid_tbl_len initialization moved down just before the loop in which it is used.