Re: [PATCH for-next 0/3] Updates for 6.5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 01, 2023 at 11:41:24PM -0400, Dennis Dalessandro wrote:
> On 6/1/23 6:54 PM, Jason Gunthorpe wrote:
> > On Fri, May 19, 2023 at 12:54:14PM -0400, Dennis Dalessandro wrote:
> >> Here are 3 more patches related/spawned out of the work to scale back the
> >> page pinning re-work. This series depends on [1] which was submitted for RC
> >> recently.
> >>
> >> [1] https://patchwork.kernel.org/project/linux-rdma/patch/168451393605.3700681.13493776139032178861.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> >>
> >> ---
> >>
> >> Brendan Cunningham (2):
> >>       IB/hfi1: Add mmu_rb_node refcount to hfi1_mmu_rb_template tracepoints
> >>       IB/hfi1: Remove unused struct mmu_rb_ops fields .insert, .invalidate
> > 
> > I took these two
> > 
> >> Patrick Kelsey (1):
> >>       IB/hfi1: Separate user SDMA page-pinning from memory type
> > 
> > Don't know what to do with this one
> 
> I'm not seeing why it's a problem. It improves our existing page pinning by
> making the code easier to follow. It makes the code easier to maintain as well
> centralizing the pinning code.
> 
> > Maybe send a complete feature.
> 
> It is a complete feature. It's just a refactoring really of an existing feature.
> It makes it more flexible to extend in the future and is the current interface
> or psm2 and libfabric.

If it was refactoring it would not add new uAPI.

The commit message said this was done for 'other than system memory'
which the driver doesn't support.

So it is all very confusing what this is all for.

> Now all of this being said, this is starting to concern me. We plan to start
> sending patches for supporting new HW soon. We were going to do this
> incrementally. 

I think we said long ago that this was the last HW that can use the
hfi1 cdev.

So you will have to think carefully about is needed. It is part of why
I don't want to take uAPI changed for incomplete features. I'm
wondering how you will fit dmabuf into hfi1 when I won't be happy if
this is done by adding dmabuf support to the cdev.

> Is that going to be considered an incomplete feature? Should we
> wait until it's all done and ship it all at once? I was envisioning doing things
> the way we did for rdmavt, showing our work so to speak, making incremental
> changes overtime as opposed to how we submitted the original hfi1 code in a
> giant blob.

I think it depends, stay away from the uapi and things are easier

Jason



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux