On Thu, Jun 11, 2015 at 1:01 AM, Jason Gunthorpe <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
