Hello, Parav. On Fri, Sep 11, 2015 at 09:09:58AM +0530, Parav Pandit wrote: > The fact is that user level application uses hardware resources. > Verbs layer is software abstraction for it. Drivers are hiding how > they implement this QP or CQ or whatever hardware resource they > project via API layer. > For all of the userland on top of verb layer I mentioned above, the > common resource abstraction is these resources AH, QP, CQ, MR etc. > Hardware (and driver) might have different view of this resource in > their real implementation. > For example, verb layer can say that it has 100 QPs, but hardware > might actually have 20 QPs that driver decide how to efficiently use > it. My uneducated suspicion is that the abstraction is just not developed enough. It should be possible to virtualize these resources through, most likely, time-sharing to the level where userland simply says "I want this chunk transferred there" and OS schedules the transfer prioritizing competing requests. It could be that given the use cases rdma might not need such level of abstraction - e.g. most users want to be and are pretty close to bare metal, but, if that's true, it also kinda is weird to build hierarchical resource distribution scheme on top of such bare abstraction. ... > > I don't know. What's proposed in this thread seems way too low level > > to be useful anywhere else. Also, what if there are multiple devices? > > Is that a problem to worry about? > > o.k. It doesn't have to be useful anywhere else. If it suffice the > need of RDMA applications, its fine for near future. > This patch allows limiting resources across multiple devices. > As we go along the path, and if requirement come up to have knob on > per device basis, thats something we can extend in future. You kinda have to decide that upfront cuz it gets baked into the interface. > > I'm kinda doubtful we're gonna have too many of these. Hardware > > details being exposed to userland this directly isn't common. > > Its common in RDMA applications. Again they may not be real hardware > resource, its just API layer which defines those RDMA constructs. It's still a very low level of abstraction which pretty much gets decided by what the hardware and driver decide to do. > > I'd say keep it simple and do the minimum. :) > > o.k. In that case new rdma cgroup controller which does rdma resource > accounting is possibly the most simplest form? > Make sense? So, this fits cgroup's purpose to certain level but it feels like we're trying to build too much on top of something which hasn't developed sufficiently. I suppose it could be that this is the level of development that rdma is gonna reach and dumb cgroup controller can be useful for some use cases. I don't know, so, yeah, let's keep it simple and avoid doing crazy stuff. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
