Re: idr_get_new_exact ?
On Mon, Sep 20, 2010 at 11:26:47PM +0200, Tejun Heo wrote: Hello, On 09/20/2010 10:35 PM, Roland Dreier wrote: Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. I agree. Wouldn't those users better off simply using radix tree? It could go either way. I was about to write the same function when playing with it for IRQ mapping, the idea being to propagate the initial tree with sparse static vectors and then switch over to dynamic IDs for virtual IRQ creation. I ended up going with a radix tree for other reasons, though. -- 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
Re: idr_get_new_exact ?
Hello, On 09/23/2010 01:42 PM, Paul Mundt wrote: On Mon, Sep 20, 2010 at 11:26:47PM +0200, Tejun Heo wrote: Hello, On 09/20/2010 10:35 PM, Roland Dreier wrote: Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. I agree. Wouldn't those users better off simply using radix tree? It could go either way. I was about to write the same function when playing with it for IRQ mapping, the idea being to propagate the initial tree with sparse static vectors and then switch over to dynamic IDs for virtual IRQ creation. I ended up going with a radix tree for other reasons, though. I see. If there are use cases where fixed and dynamic IDs need to be mixed, no objection from me. Thanks. -- tejun -- 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
Re: idr_get_new_exact ?
On Mon, 20 Sep 2010 16:11:31 +0200 Ohad Ben-Cohen o...@wizery.com wrote: Occasionally, drivers care about the value that idr associates with their pointers. Today we have idr_get_new_above() which allocates a new idr entry above or equal to a given starting id, but sometimes drivers need to force an exact value. To overcome this small API gap, drivers are wrapping idr_get_new_above and then either BUG_ON() or just call idr_remove() and returns -EBUSY when idr allocates them an id which is different than their requested value. There are only a handful of users who need this (see below. especially note the i2c comment :), but it might be nice to have such an API (a bit less of code, and a bit less error prone). Would something like the below be desirable/acceptable ? It seems OK to me - it's an improvement over what we have now. (untested. and i just picked the simplest and straight-forward way to implement this; obviously it's not optimal since there's no reason to even allocate an id if we know it's not the id we're looking for. but it's enough to get the idea, it's not a hot path, and it's what drivers are doing today) Sure, we can speed it up later if that appears to be necessary. -- 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
Re: idr_get_new_exact ?
On 09/20/2010 02:31 PM, Andrew Morton wrote: On Mon, 20 Sep 2010 16:11:31 +0200 Ohad Ben-Coheno...@wizery.com wrote: Occasionally, drivers care about the value that idr associates with their pointers. Today we have idr_get_new_above() which allocates a new idr entry above or equal to a given starting id, but sometimes drivers need to force an exact value. To overcome this small API gap, drivers are wrapping idr_get_new_above and then either BUG_ON() or just call idr_remove() and returns -EBUSY when idr allocates them an id which is different than their requested value. There are only a handful of users who need this (see below. especially note the i2c comment :), but it might be nice to have such an API (a bit less of code, and a bit less error prone). Would something like the below be desirable/acceptable ? It seems OK to me - it's an improvement over what we have now. Looks ok to me also. This is exactly what cxgb* needs. IE the driver manages the ID space and never expects an idr insertion to fail because its already inserted. That constitutes a driver bug (which is why the BUG_ON() is there :)). Steve. -- 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
Re: idr_get_new_exact ?
Occasionally, drivers care about the value that idr associates with their pointers. Today we have idr_get_new_above() which allocates a new idr entry above or equal to a given starting id, but sometimes drivers need to force an exact value. To overcome this small API gap, drivers are wrapping idr_get_new_above and then either BUG_ON() or just call idr_remove() and returns -EBUSY when idr allocates them an id which is different than their requested value. Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. - R. -- 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
Re: idr_get_new_exact ?
Hello, On 09/20/2010 10:35 PM, Roland Dreier wrote: Looks fine to me as an improvement over the status quo, but I wonder how many of these places could use the radix_tree stuff instead? If you're not using the ability of the idr code to assign an id for you, then it seems the radix_tree API is a better fit. I agree. Wouldn't those users better off simply using radix tree? Thanks. -- tejun -- 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
