From mboxrd@z Thu Jan 1 00:00:00 1970 From: swise@opengridcomputing.com (Steve Wise) Date: Sun, 3 Jun 2018 13:27:59 -0500 Subject: [PATCH v3 1/3] nvme-rdma: correctly check for target keyed sgl support In-Reply-To: <702f1949-02eb-07e4-f101-58c32929b29d@grimberg.me> References: <14063C7AD467DE4B82DEDB5C278E8663B38EE822@FMSMSX108.amr.corp.intel.com> <3acbea43-d777-88a5-0059-10275655d545@opengridcomputing.com> <8da47cd4-44d5-2229-ef82-26d165dfc245@opengridcomputing.com> <20180531170201.GB31715@lst.de> <20180531172554.GA32068@lst.de> <702f1949-02eb-07e4-f101-58c32929b29d@grimberg.me> Message-ID: <010001d3fb68$99d01d80$cd705880$@opengridcomputing.com> > -----Original Message----- > From: Sagi Grimberg > Sent: Sunday, June 3, 2018 6:57 AM > To: hch at lst.de; Steve Wise > Cc: Ruhl, Michael J ; axboe at kernel.dk; Busch, > Keith ; linux-nvme at lists.infradead.org; > parav at mellanox.com; maxg at mellanox.com; linux-rdma at vger.kernel.org > Subject: Re: [PATCH v3 1/3] nvme-rdma: correctly check for target keyed sgl > support > > > >> Ok then, I will leave them as bit numbers... > > > > Btw, modulo the debug printk 1 & 2 look fine to me and I'd like to > > pull them in. Sagi, are you ok with the patches? > > I'd like to see a version that avoids higher order allocations first > as we can have a non negligible number of these allocations. > If it turns out too much of hassle we can stay with this. He's referring to patch 1 and 2, which are the host side. No page allocations. Also, I made the changes to avoid higher order allocations for patch 3. Testing now. I'll send it out tomorrow. Steve.