linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: devel@driverdev.osuosl.org,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Mitko Haralanov <mitko.haralanov@intel.com>,
	Doug Ledford <dledford@redhat.com>,
	Kamal Heib <kamalh@mellanox.com>
Subject: Re: [PATCH 5/9] staging/rdma/hfi1: Add function stubs for TID caching
Date: Thu, 19 Nov 2015 17:06:30 -0800	[thread overview]
Message-ID: <20151120010630.GA25032@kroah.com> (raw)
In-Reply-To: <CAJ3xEMiLz=kgeQhx07WFWtNzcPwy2ZL9fs0SZkSpVd6+reGUVA@mail.gmail.com>

On Thu, Nov 12, 2015 at 07:58:54AM +0200, Or Gerlitz wrote:
> On Sat, Oct 31, 2015 at 12:41 AM,  <ira.weiny@intel.com> wrote:
> > From: Mitko Haralanov <mitko.haralanov@intel.com>
> >
> > Add mmu notify helper functions and TID caching function stubs in preparation
> > for the TID caching implementation.
> >
> > TID caching makes use of the MMU notifier to allow the driver to respond to the
> > user freeing memory which is allocated to the HFI.
> >
> > This patch implements the basic MMU notifier functions to insert, find and
> > remove buffer pages from memory based on the mmu_notifier being invoked.
> >
> > In addition it places stubs in place for the main entry points by follow on
> > code.
> >
> > Follow up patches will complete the implementation of the interaction with user
> > space and makes use of these functions.
> 
> So this is an wholy orthogonal mechanism for memory registrations or
> de-registrations vs
> what's supported by the upstream RDMA stack to which this driver
> attempts to be a HW provider, right?
> 
> Ira, Mike - why do that?
> 
> 2. Greg - I read an earlier comment you made that a driver in staging
> need to be 1st
> and most **fixed** with patches such that the TODO items to get it out
> of staging are
> addressed. I see here every day long train of features going into this
> driver, should the
> focus need to be elsewhere, according to the staging guidelines?

I've already complained about this, supposedly these are things that are
needed to get it out of staging...

And yes, you are correct.

thanks,

greg k-h

  reply	other threads:[~2015-11-20  1:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 22:41 [PATCH 0/9] staging/rdma/hfi1: Fix bugs and performance issues ira.weiny
2015-10-30 22:41 ` [PATCH 1/9] staging/rdma/hfi1: Remove file pointer macros ira.weiny
2015-10-30 22:41 ` [PATCH 3/9] staging/rdma/hfi1: Remove unnecessary include files ira.weiny
2015-10-30 22:41 ` [PATCH 4/9] staging/rdma/hfi1: Move macros to a common header ira.weiny
2015-10-30 22:41 ` [PATCH 5/9] staging/rdma/hfi1: Add function stubs for TID caching ira.weiny
     [not found]   ` <1446244918-12089-6-git-send-email-ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-11-12  5:58     ` Or Gerlitz
2015-11-20  1:06       ` Greg Kroah-Hartman [this message]
     [not found]         ` <20151120010630.GA25032-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2015-11-20  8:21           ` Or Gerlitz
2015-10-30 22:41 ` [PATCH 7/9] staging/rdma/hfi1: move hfi1_migrate_qp ira.weiny
     [not found] ` <1446244918-12089-1-git-send-email-ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-10-30 22:41   ` [PATCH 2/9] staging/rdma/hfi1: Clean up macro indentation ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-10-30 22:41   ` [PATCH v4 6/9] staging/rdma/hfi1: Implement Expected Receive TID caching ira.weiny-ral2JQCrhuEAvxtiuMwx3w
     [not found]     ` <1446244918-12089-7-git-send-email-ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-10-30 22:47       ` Greg KH
2015-10-30 22:41   ` [PATCH v4 8/9] staging/rdma/hfi1: Use parallel workqueue for SDMA engines ira.weiny-ral2JQCrhuEAvxtiuMwx3w
2015-10-30 22:41   ` [PATCH 9/9] staging/rdma/hfi: pre-compute sc and sde for RC/UC QPs ira.weiny-ral2JQCrhuEAvxtiuMwx3w

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151120010630.GA25032@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=dledford@redhat.com \
    --cc=gerlitz.or@gmail.com \
    --cc=kamalh@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mitko.haralanov@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).