On 4/26/2015 8:20 PM, Or Gerlitz wrote:
On Thu, Mar 26, 2015 at 12:19 AM, Somnath Kotur
<somnath.kotur@xxxxxxxxxx> wrote:
From: Matan Barak <matanb@xxxxxxxxxxxx>
In order to manage multiple types, vlans and MACs per GID, we
need to store them along the GID itself. We store the net device
as well, as sometimes GIDs should be handled according to the
net device they came from. Since populating the GID table should
be identical for every RoCE provider, the GIDs table should be
handled in ib_core.
Adding a GID cache table that supports a lockless find, add and
delete gids. The lockless nature comes from using a unique
sequence number per table entry and detecting that while reading/
writing this sequence wasn't changed.
Matan, please use existing mechanism which fits the problem you are
trying to solve, I guess one of RCU or seqlock should do the job.
seqcount fits this problem better. Since if a write and read are done in
parallel, there's a good chance we read an out of date entry and we are
going to use a GID entry that's going to change in T+epsilon, so RCU
doesn't really have an advantage here.
The current implementation is a bit more efficient than seqcount, as it
allows early termination of read-while-write (because the write puts a
known "currently updating" value that the read knows to ignore). AFAIK,
this doesn't exist in the current seqcount implementation. However,
since this isn't a crucial data-path, I'll change that to seqcount.
seqcount is preferred over seqlock, as I don't need the spinlock in seqlock.
Or.
Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
