> On Mon, Apr 22, 2013 at 7:46 PM, Or Gerlitz <or.gerl...@gmail.com> wrote: > > Sean, Tzahi -- I understand now that there have been few talkings @ > > the OFA meeting re this patch set. So what's the way to move forward, > > any concrete feedback that needs to be addressed here? This series is > > hanging since May 2012 and I'd like to see it gets in for 3.10, now if > > indeed Sean is OK with the general framework, please suggest. > > Sean, > > I understand that following some conversations help at the OFA > meetings you kind of took back the concerns you raised regarding the > concept of the verbs level QP group which is used by this series to > implement RSS and TSS, can you acknoledge that?
No - I agree with the RSS/TSS concept. That I've never had an issue with. My issue is that the current verbs API appears to be a poor fit. I don't have a good answer for an alternative. Conceptually, RSS/TSS are a set of send/receive work queues all belonging to the same transport level address. There's no parent-child relationship or needed pairing of send and receive queues together in order to form a group. Personally, I'd like to see a way that better captures the notion of a 'set of work queues with the same address'. For example, it makes more sense to me if a user created/destroyed the work queues together, and if the WQs were viewed as being in a single state (INIT, RTR, RTS...). I'm just thinking out loud here, hoping that it spurs ideas, but if we added a call like: struct ib_qp *ib_create_wq_array/set/group(...); then added the ability to specify which WQ a specific send or receive should be posted to, it may do a better job of capturing RSS/TSS concepts, but still make use of the existing calls. (Underneath this, the driver can allocate actual QPs with sequential QPNs or whatever is required, but that's not exposed.) Obviously, I haven't thought through specifics. I'll try to meet up with Diego and Tzahi tonight or tomorrow to discuss this further. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
