Re: [PATCH] iscsid: Add qedi ping transport hook

Applied. Please note that pull requests via github are easier to apply than traditional patch emails. On Wednesday, April 26, 2017 at 2:27:03 AM UTC-7, Nilesh Javali wrote: > > iscsiuio ping is operational for qedi. > Add missing qedi transport hook for ping support. > > Signed-off-by: Nilesh

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > blkfront is one of the drivers I looked at, and it appears to only be > memcpying with the bvec_data pointer, so I wonder why it does not use > sg_copy_X_buffer instead.. Yes, sort of... But you'd potentially end up calling sg_copy_to_buffer

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 26/04/17 01:37 AM, Roger Pau Monné wrote: > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: >> Straightforward conversion to the new helper, except due to the lack >> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in >> certain cases in the future. >> >>

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 26/04/17 01:44 AM, Christoph Hellwig wrote: > I think we'll at least need a draft of those to make sense of these > patches. Otherwise they just look very clumsy. Ok, what follows is a draft patch attempting to show where I'm thinking of going with this. Obviously it will not compile because

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 09:27 AM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > How about first switching as many call sites as possible to use > sg_copy_X_buffer instead of kmap? Yeah, I could look at doing that first. One problem is we might get more Naks

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe >> Cc: Herbert Xu

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote: > Ok, well for starters I think you are mistaken about kmap being able to > fail. I'm having a hard time finding many users of that function that > bother to check for an error when calling it. A quick audit of the arch code shows