Re: [PATCH for-next V5 00/12] Move RoCE GID management to IB/Core

Or Gerlitz
2015-06-12T12:29:25Z

On Thu, Jun 11, 2015 at 1:01 AM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
> On Wed, Jun 10, 2015 at 11:19:03PM +0300, Matan Barak wrote:
>
>> > Sure gid_type is gone, but I didn't say roceve2 specific, I said
>> > latent elements. ie I'm assuming reasons for the scary locking are
>> > because the ripped out rocev2 code needed it? And some of the
>> > complexity that looks pointless now was supporting ripped out rocev2
>> > elements? That is not necessarily bad, but the code had better be good
>> > quailty and working..
>>
>> Why do you think the locks have anything to do with roce v2?
>
> What else could they be for? The current mlx4 driver doesn't use use
> aggressive performance locking.
>
> After writing this email, I am of the opinion that the locking should
> be simplified to rwsem and mutex, and every use of rcu, READ_ONCE and
> seqlock should be ditched.

Hi Jason,

I understand the email thread went down into further details from this
point and on, but still, I'd like to stop here and ask for short
clarification -- my understanding of things re this reader-writer
scheme is the following:

1. some reader/s can't be made to sleep as they make calls in atomic context
and hence it wouldn't be correct to use RW semaphore

2. some writers go to sleep (invoke driver call to the firmware) and
hence they can't be holding RW spinlock

Agree? if not, can you shortly say what's wrong in these assumptions,
or I should just deeply read the thread.

B/c if these assumptions are correct, seqlock/seqcount seem to me very
much like the right approach. It addresses the constraints 1 and 2
above, simple/robust to implement/use

so?

Or.