Re: [PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-05-02 Thread Bart Van Assche
On Tue, 2017-05-02 at 09:25 -0600, Jens Axboe wrote: > On 05/02/2017 09:16 AM, Christoph Hellwig wrote: > > Any reason for the move from ->end_io_data to ->special? I thought > > that ->special was something we'd get rid of sooner or later now > > that we can have additional per-cmd data even for

Re: [PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-05-02 Thread Christoph Hellwig
This looks reasonable to me, although of course I don't have a way to test it. Any reason for the move from ->end_io_data to ->special? I thought that ->special was something we'd get rid of sooner or later now that we can have additional per-cmd data even for !mq.

Re: [PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-05-02 Thread Jens Axboe
On 05/02/2017 07:53 AM, Jens Axboe wrote: > On 05/02/2017 01:28 AM, Christoph Hellwig wrote: >> Looks fine for now: >> >> Reviewed-by: Christoph Hellwig >> >> But rather sooner than later we need to make this path at least go >> through the normal end_request processing. Without

Re: [PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-05-02 Thread Jens Axboe
On 05/02/2017 01:28 AM, Christoph Hellwig wrote: > Looks fine for now: > > Reviewed-by: Christoph Hellwig > > But rather sooner than later we need to make this path at least go > through the normal end_request processing. Without that we're just > bound to run into problems like

Re: [PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-05-02 Thread Christoph Hellwig
Looks fine for now: Reviewed-by: Christoph Hellwig But rather sooner than later we need to make this path at least go through the normal end_request processing. Without that we're just bound to run into problems like we had with the tag changes again when the driver is using the

[PATCH 4/6] mtip32xx: convert internal command issue to block IO path

2017-04-28 Thread Jens Axboe
The driver special cases certain things for command issue, depending on whether it's an internal command or not. Make the internal commands use the regular infrastructure for issuing IO. Since this is an 8-group souped up AHCI variant, we have to deal with NCQ vs non-queueable commands. Do this