Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-04-02 Thread Benjamin Herrenschmidt
On Fri, 2015-04-03 at 07:22 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2015-04-02 at 12:21 -0400, David Miller wrote: > > From: Sowmini Varadhan > > Date: Thu, 2 Apr 2015 08:51:52 -0400 > > > > > do I need to resubmit this without the RFC tag? Perhaps I should > > > have dropped that some tim

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-04-02 Thread Benjamin Herrenschmidt
On Thu, 2015-04-02 at 12:21 -0400, David Miller wrote: > From: Sowmini Varadhan > Date: Thu, 2 Apr 2015 08:51:52 -0400 > > > do I need to resubmit this without the RFC tag? Perhaps I should > > have dropped that some time ago. > > I want to hear from the powerpc folks whether they can positively

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-04-02 Thread David Miller
From: Sowmini Varadhan Date: Thu, 2 Apr 2015 08:51:52 -0400 > do I need to resubmit this without the RFC tag? Perhaps I should > have dropped that some time ago. I want to hear from the powerpc folks whether they can positively adopt the new generic code or not. _

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-04-02 Thread Sowmini Varadhan
On (03/31/15 23:12), David Miller wrote: > > It's much more amortized with smart buffering strategies, which are > common on current generation networking cards. > > There you only eat one map/unmap per "PAGE_SIZE / rx_pkt_size". > > Maybe the infiniband stuff is doing things very suboptimally,

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread David Miller
From: Sowmini Varadhan Date: Tue, 31 Mar 2015 21:08:18 -0400 > I'm starting to wonder if some approximation of dma premapped > buffers may be needed. Doing a map/unmap on each packet is expensive. It's much more amortized with smart buffering strategies, which are common on current generation n

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread Sowmini Varadhan
On 03/31/2015 09:01 PM, Benjamin Herrenschmidt wrote: On Tue, 2015-03-31 at 14:06 -0400, Sowmini Varadhan wrote: Having bravely said that.. the IB team informs me that they see a 10% degradation using the spin_lock as opposed to the trylock. one path going forward is to continue processing thi

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread Benjamin Herrenschmidt
On Tue, 2015-03-31 at 14:06 -0400, Sowmini Varadhan wrote: > Having bravely said that.. > > the IB team informs me that they see a 10% degradation using > the spin_lock as opposed to the trylock. > > one path going forward is to continue processing this patch-set > as is. I can investigate this

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread David Miller
From: Sowmini Varadhan Date: Tue, 31 Mar 2015 14:06:42 -0400 > Having bravely said that.. > > the IB team informs me that they see a 10% degradation using > the spin_lock as opposed to the trylock. > > one path going forward is to continue processing this patch-set > as is. I can investigate

Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread Sowmini Varadhan
On (03/31/15 10:40), Sowmini Varadhan wrote: > > I've not heard back from the IB folks, but I'm going to make > a judgement call here and go with the spin_lock. *If* they > report some significant benefit from the trylock, probably > need to revisit this (and then probably start by re-exmaining >

[PATCH v8 RFC 0/3] Generic IOMMU pooled allocator

2015-03-31 Thread Sowmini Varadhan
Addresses BenH comments with one exception: I've left the IOMMU_POOL_HASH as is, so that powerpc can tailor it to their convenience. I've not heard back from the IB folks, but I'm going to make a judgement call here and go with the spin_lock. *If* they report some significant benefit from the try