RE: Performance drop due to "blk-mq-sched: improve sequential I/O performance"

> > I have created internal code changes based on below RFC and using irq > > poll CPU lockup issue is resolved. > > https://www.spinics.net/lists/linux-scsi/msg116668.html > > Could we use the 1:1 mapping and not apply out-of-tree irq poll in the > following test? So that we can keep at same page

RE: Performance drop due to "blk-mq-sched: improve sequential I/O performance"

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Wednesday, May 2, 2018 3:17 PM > To: Kashyap Desai > Cc: linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org > Subject: Re: Performance drop due to "blk-mq-sched: improve sequential I/O &g

Performance drop due to "blk-mq-sched: improve sequential I/O performance"

Hi Ming, I was running some performance test on latest 4.17-rc and figure out performance drop (approximate 15% drop) due to below patch set. https://marc.info/?l=linux-block=150802309522847=2 I observed drop on latest 4.16.6 stable and 4.17-rc kernel as well. Taking bisect approach, figure out

RE: MegaCli fails to communicate with Raid-Controller

> -Original Message- > From: Volker Schwicking [mailto:volker.schwick...@godaddy.com] > Sent: Thursday, April 26, 2018 8:22 PM > To: Kashyap Desai > Cc: Martin K. Petersen; linux-scsi@vger.kernel.org; Sumit Saxena; > Shivasharan > Srikanteshwara > Subject: Re: Mega

RE: MegaCli fails to communicate with Raid-Controller

> > Interesting. What is considered old and new? I have a third machine "Dell > R515, MegaRAID SAS 2108”, is that considered new? Its running the same > Xen/Kernel/Megacli-versions as the other two, but the error does not > occur. Nope this is also old controller. When I say new controller, It is

RE: MegaCli fails to communicate with Raid-Controller

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, April 18, 2018 10:43 PM > To: volker.schwick...@godaddy.com > Cc: linux-scsi@vger.kernel.org; Kashyap Desai; Sumit Saxena > Subject: Re: MegaCli fails to communicate wi

smp affinity and kworker io submission

Hi, I am running FIO script on Linux 4.15. This is generic behavior even on 3.x kernels as well. I wanted to know if my observation is correct or not. Here is FIO command - numactl -C 0-2 fio single --bs=4k --iodepth=64 --rw=randread --ioscheduler=none --group_report --numjobs=2 If driver is

RE: [PATCH V5 1/5] scsi: hpsa: fix selection of reply queue

> -Original Message- > From: Artem Bityutskiy [mailto:dedeki...@gmail.com] > Sent: Monday, March 19, 2018 8:12 PM > To: h...@lst.de; Thomas Gleixner > Cc: linux-bl...@vger.kernel.org; snit...@redhat.com; h...@suse.de; > mr...@linux.ee; linux-scsi@vger.kernel.org; don.br...@microsemi.com; >

RE: [PATCH V5 2/5] scsi: megaraid_sas: fix selection of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, March 13, 2018 3:13 PM > To: James Bottomley; Jens Axboe; Martin K . Petersen > Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; linux- > bl...@vger.kernel.org; Meelis Roos; Don Br

RE: [PATCH V4 2/4] scsi: megaraid_sas: fix selection of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Friday, March 9, 2018 5:33 PM > To: Kashyap Desai > Cc: James Bottomley; Jens Axboe; Martin K . Petersen; Christoph Hellwig; > linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org; Meelis

RE: [PATCH V4 2/4] scsi: megaraid_sas: fix selection of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Friday, March 9, 2018 9:02 AM > To: James Bottomley; Jens Axboe; Martin K . Petersen > Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; linux- > bl...@vger.kernel.org; Meelis Roos; Don Br

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Thursday, March 8, 2018 4:54 PM > To: Kashyap Desai > Cc: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike Snitzer; > linux-scsi@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sa

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Thursday, March 8, 2018 6:46 AM > To: Kashyap Desai > Cc: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike Snitzer; > linux-scsi@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sa

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> > > > Also one observation using V3 series patch. I am seeing below Affinity > > mapping whereas I have only 72 logical CPUs. It means we are really > > not going to use all reply queues. > > e.a If I bind fio jobs on CPU 18-20, I am seeing only one reply queue > > is used and that may lead to

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Wednesday, March 7, 2018 10:58 AM > To: Kashyap Desai > Cc: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike Snitzer; > linux-scsi@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar

RE: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

ecke; Arun Easi; Omar Sandoval; > Martin K . Petersen; James Bottomley; Christoph Hellwig; Kashyap Desai; > Peter > Rivera; Meelis Roos > Subject: Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue > > On Fri, 2018-03-02 at 15:03 +, Don Brace wrote: > > > -Or

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Laurence Oberman [mailto:lober...@redhat.com] > Sent: Wednesday, February 28, 2018 9:52 PM > To: Ming Lei; Kashyap Desai > Cc: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike > Snitzer; > linux-scsi@vger.kernel.org; Hanne

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

gt; To: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike Snitzer > Cc: linux-scsi@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sandoval; > Martin K . Petersen; James Bottomley; Christoph Hellwig; Don Brace; Kashyap > Desai; Peter Rivera; Laurence Oberman; Ming Lei >

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, February 13, 2018 6:11 AM > To: Kashyap Desai > Cc: Hannes Reinecke; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun E

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Sunday, February 11, 2018 11:01 AM > To: Kashyap Desai > Cc: Hannes Reinecke; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun E

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Friday, February 9, 2018 11:01 AM > To: Kashyap Desai > Cc: Hannes Reinecke; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun Easi; Omar

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Thursday, February 8, 2018 10:23 PM > To: Hannes Reinecke > Cc: Kashyap Desai; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun E

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Wednesday, February 7, 2018 5:53 PM > To: Hannes Reinecke > Cc: Kashyap Desai; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun E

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, February 6, 2018 6:02 PM > To: Kashyap Desai > Cc: Hannes Reinecke; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun Easi; Omar

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, February 6, 2018 1:35 PM > To: Kashyap Desai > Cc: Hannes Reinecke; Jens Axboe; linux-bl...@vger.kernel.org; Christoph > Hellwig; Mike Snitzer; linux-scsi@vger.kernel.org; Arun Easi; Omar

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

> > We still have more than one reply queue ending up completion one CPU. > > pci_alloc_irq_vectors(PCI_IRQ_AFFINITY) has to be used, that means > smp_affinity_enable has to be set as 1, but seems it is the default setting. > > Please see kernel/irq/affinity.c, especially

RE: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce force_blk_mq

gt; Petersen; > James Bottomley; Christoph Hellwig; Don Brace; Kashyap Desai; Peter > Rivera; > Paolo Bonzini; Laurence Oberman > Subject: Re: [PATCH 0/5] blk-mq/scsi-mq: support global tags & introduce > force_blk_mq > > On 02/03/2018 05:21 AM, Ming Lei wrote: > >

RE: [RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Friday, February 2, 2018 3:44 PM > To: Kashyap Desai > Cc: linux-scsi@vger.kernel.org; Peter Rivera > Subject: Re: [RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing of > reply

RE: [LSF/MM TOPIC] irq affinity handling for high CPU count machines

> > > > Today I am looking at one megaraid_sas related issue, and found > > > > pci_alloc_irq_vectors(PCI_IRQ_AFFINITY) is used in the driver, so > > > > looks each reply queue has been handled by more than one CPU if > > > > there are more CPUs than MSIx vectors in the system, which is done > > >

RE: [LSF/MM TOPIC] irq affinity handling for high CPU count machines

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Thursday, February 1, 2018 9:50 PM > To: Ming Lei > Cc: lsf...@lists.linux-foundation.org; linux-scsi@vger.kernel.org; linux- > n...@lists.infradead.org; Kashyap Desai > Subject: Re: [LSF/M

RE: [RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing of reply queue

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Monday, January 29, 2018 2:29 PM > To: Kashyap Desai; linux-scsi@vger.kernel.org; Peter Rivera > Subject: Re: [RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing > of > reply queue &g

RE: [LSF/MM TOPIC] irq affinity handling for high CPU count machines

.@lists.infradead.org; Kashyap > Desai > Subject: Re: [LSF/MM TOPIC] irq affinity handling for high CPU count > machines > > On 01/29/18 07:41, Elliott, Robert (Persistent Memory) wrote: > >> -Original Message- > >> From: Linux-nvme [mailto:linux-nvme-boun...@

RE: [RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing of reply queue

> > In Summary, > CPU completing IO which is not contributing to IO submission, may cause cpu > lockup. > If CPUs count to MSI-X vector count ratio is X:1 (where X > 1) then using irq poll > interface, we can avoid the CPU lockups and by equally distributing the > interrupts among the enabled

RE: [RFC 1/2] mpt3sas/megaraid_sas : irq poll to avoid CPU hard and soft lockups

> -Original Message- > From: Johannes Thumshirn [mailto:jthumsh...@suse.de] > Sent: Monday, January 15, 2018 5:49 PM > To: Kashyap Desai > Cc: linux-scsi@vger.kernel.org; Peter Rivera > Subject: Re: [RFC 1/2] mpt3sas/megaraid_sas : irq poll to avoid CPU hard and > so

RE: [PATCH 13/14] megaraid_sas: NVME passthru command support

018 11:37 PM > To: Keith Busch > Cc: dgilb...@interlog.com; Bart Van Assche; h...@infradead.org; Kashyap > Desai; Shivasharan Srikanteshwara; Sumit Saxena; linux- > n...@lists.infradead.org; Peter Rivera; linux-scsi@vger.kernel.org > Subject: RE: [PATCH 13/14] megaraid_sas: NVME

[RFC 2/2] mpt3sas/megaraid_sas : reply queue load balancing

Patch for Fix-2 explained in PATCH 0. Signed-off-by: Kashyap Desai < kashyap.de...@broadcom.com> --- mpt3sas/mpt3sas_base.c | 5 - mpt3sas/mpt3sas_base.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/mpt3sas/mpt3sas_base.c b/mpt3sas/mpt3sas_base.c index 0

[RFC 1/2] mpt3sas/megaraid_sas : irq poll to avoid CPU hard and soft lockups

Patch for Fix-1 explained in PATCH 0. Signed-off-by: Kashyap Desai < kashyap.de...@broadcom.com> --- mpt3sas/mpt3sas_base.c | 67 ++ mpt3sas/mpt3sas_base.h | 4 +++ 2 files changed, 55 insertions(+), 17 deletions(-) diff --git a/m

[RFC 0/2] mpt3sas/megaraid_sas : irq poll and load balancing of reply queue

Hi All - We have seen cpu lock up issue from fields if system has greater (more than 96) logical cpu count. SAS3.0 controller (Invader series) supports at max 96 msix vector and SAS3.5 product (Ventura) supports at max 128 msix vectors. This may be a generic issue (if PCI device support

RE: [PATCH 13/14] megaraid_sas: NVME passthru command support

> -Original Message- > From: Douglas Gilbert [mailto:dgilb...@interlog.com] > Sent: Wednesday, January 10, 2018 2:21 AM > To: Christoph Hellwig; Kashyap Desai > Cc: Shivasharan Srikanteshwara; linux-scsi@vger.kernel.org; Sumit Saxena; > linux-n...@lists.infradead

RE: [PATCH 13/14] megaraid_sas: NVME passthru command support

> -Original Message- > From: Keith Busch [mailto:keith.bu...@intel.com] > Sent: Wednesday, January 10, 2018 4:53 AM > To: Douglas Gilbert > Cc: Christoph Hellwig; Kashyap Desai; Shivasharan Srikanteshwara; Sumit > Saxena; Peter Rivera; linux-n...@lists.infrade

RE: [PATCH 13/14] megaraid_sas: NVME passthru command support

Chris - Overall NVME support behind MR controller is really a SCSI device. On top of that, for MegaRaid, NVME device can be part of Virtual Disk and those drive will not be exposed to the driver. User application may like to talk to hidden NVME devices (part of VDs). This patch will extend the

RE: system hung up when offlining CPUs

> > On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote: > > + linux-scsi and maintainers of megasas > > > > When offlining CPU, I/O stops. Do you have any ideas? > > > > On 09/07/2017 04:23 PM, YASUAKI ISHIMATSU wrote: > >> Hi Mark and Christoph, > >> > >> Sorry for the late reply. I appreciated that

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Monday, August 07, 2017 7:48 PM > To: Kashyap Desai; Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu Subramani; martin.peter...@oracle.com; linux- > s...@vger.

RE: [PATCH v2 00/13] mpt3sas driver NVMe support:

> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Saturday, August 05, 2017 8:12 PM > To: Christoph Hellwig; Hannes Reinecke > Cc: Suganath Prabu S; martin.peter...@oracle.com; linux- > s...@vger.kernel.org; sathya.prak...@broadcom.com; >

RE: [PATCH v2 11/15] megaraid_sas: Set device queue_depth same as HBA can_queue value in scsi-mq mode

> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Tuesday, July 11, 2017 7:28 PM > To: Shivasharan S > Cc: linux-scsi@vger.kernel.org; martin.peter...@oracle.com; > the...@redhat.com; j...@linux.vnet.ibm.com; > kashyap.de...@broadcom.com;

RE: [PATCH 13/47] megaraid: pass in NULL scb for host reset

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Hannes Reinecke > Sent: Wednesday, June 28, 2017 9:00 PM > To: Sumit Saxena; Christoph Hellwig > Cc: Martin K. Petersen; James Bottomley; linux-scsi@vger.kernel.org; >

RE: [RESEND][PATCH 07/10][SCSI]mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Thursday, April 27, 2017 3:55 AM > To: Sreekanth Reddy > Cc: Martin K. Petersen; j...@kernel.org; linux-scsi@vger.kernel.org; linux- >

RE: out of range LBA using sg_raw

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, March 08, 2017 10:03 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-ker...@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of r

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 9:37 PM > To: Kashyap Desai > Cc: Christoph Hellwig; linux-ker...@vger.kernel.org; linux- > s...@vger.kernel.org > Subject: Re: out of range LBA using sg_r

RE: out of range LBA using sg_raw

e LBA using sg_raw > > On Wed, 2017-03-08 at 21:29 +0530, Kashyap Desai wrote: > > Also one more fault I can generate using below sg_raw command - > > > > "sg_raw -r 32k /dev/sdx 28 00 01 4f ff ff 00 00 08 00" > > > > Provide more scsi data length comp

RE: out of range LBA using sg_raw

> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Wednesday, March 08, 2017 8:41 PM > To: Kashyap Desai > Cc: linux-ker...@vger.kernel.org; linux-scsi@vger.kernel.org > Subject: Re: out of range LBA using sg_raw > > Hi Kashyap, &

RE: [PATCH] megaraid_sas: enable intx only if msix request fails

> > --- > > drivers/scsi/megaraid/megaraid_sas_base.c | 6 +- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c > > b/drivers/scsi/megaraid/megaraid_sas_base.c > > index 7ac9a9e..82a8ec8 100644 > > ---

RE: [PATCH] megaraid_sas: enable intx only if msix request fails

Any feedback ? We have few more patches to be submitted, so looking for review of this pending patch. Thanks, Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Thursday, March 02, 2017 4:24 PM > To: linux-scsi@vger.ker

out of range LBA using sg_raw

Hi - Need help to understand if below is something we should consider to be fixed in megaraid_sas driver or call as unreal exposure. I have created slice VD of size 10GB (raid 1) using 2 drives. Each Physical Drive size is 256GB. Last LBA of the VD and actual Physical disk associated with

[PATCH] megaraid_sas: enable intx only if msix request fails

- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/me

RE: [PATCH 00/10] mpt3sas: full mq support

> > - Later we can explore if nr_hw_queue more than one really add benefit. > > From current limited testing, I don't see major performance boost if > > we have nr_hw_queue more than one. > > > Well, the _actual_ code to support mq is rather trivial, and really serves > as a > good testbed for

RE: [PATCH 00/10] mpt3sas: full mq support

> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Wednesday, February 15, 2017 3:35 PM > To: Kashyap Desai; Sreekanth Reddy > Cc: Christoph Hellwig; Martin K. Petersen; James Bottomley; linux- > s...@vger.kernel.org; Sathya Prakash Veerichetty; P

RE: [PATCH 00/10] mpt3sas: full mq support

> > > Hannes, > > Result I have posted last time is with merge operation enabled in block > layer. If I disable merge operation then I don't see much improvement > with > multiple hw request queues. Here is the result, > > fio results when nr_hw_queues=1, > 4k read when numjobs=24: io=248387MB,

[PATCH] return valid data buffer length in scsi_bufflen() API using RQF_SPECIAL_PAYLOAD

00 Root cause is SCSI buffer length and DMA buffer length miss match for WRITE SAME command. Fix - return valid data buffer length in scsi_bufflen() API using RQF_SPECIAL_PAYLOAD Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> --- diff --git a/include/scsi/scsi_cmnd.h b/includ

RE: [PATCH v2 21/39] megaraid_sas: big endian support changes

> +static inline void set_num_sge(struct RAID_CONTEXT_G35 rctx_g35, > +u16 sge_count) > +{ > + rctx_g35.u.bytes[0] = (u8)(sge_count & NUM_SGE_MASK_LOWER); > + rctx_g35.u.bytes[1] |= (u8)((sge_count >> NUM_SGE_SHIFT_UPPER) > +

RE: [PATCH v2 19/39] megaraid_sas: MR_TargetIdToLdGet u8 to u16 and avoid invalid raid-map access

> Signed-off-by: Shivasharan S <shivasharan.srikanteshw...@broadcom.com> > Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> In this patch series, we are done with review but this particular patch missed Review-by tag. Kashyap

RE: [PATCH v2 03/39] megaraid_sas: raid 1 fast path code optimize

> > +static inline void > > +megasas_complete_r1_command(struct megasas_instance *instance, > > + struct megasas_cmd_fusion *cmd) { > > + u8 *sense, status, ex_status; > > + u32 data_length; > > + u16 peer_smid; > > + struct fusion_context *fusion; > > + struct

RE: [PATCH 13/39] megaraid_sas : set residual bytes count during IO compeltion

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Tuesday, February 07, 2017 5:22 AM > To: Shivasharan S > Cc: linux-scsi@vger.kernel.org; martin.peter...@oracle.com; > the...@redhat.com; j...@linux.vnet.ibm.com; > kashyap.de...@broadcom.com;

RE: [PATCH 33/39] megaraid_sas: call flush_scheduled_work during controller shutdown/detach

> -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Monday, February 06, 2017 10:48 PM > To: 'Tomas Henzl'; Shivasharan Srikanteshwara; 'linux-scsi@vger.kernel.org' > Cc: 'martin.peter...@oracle.com'; 'j...@linux.vnet.ibm.com'; Sum

RE: [PATCH 33/39] megaraid_sas: call flush_scheduled_work during controller shutdown/detach

m; > h...@suse.com > Subject: Re: [PATCH 33/39] megaraid_sas: call flush_scheduled_work during > controller shutdown/detach > > On 6.2.2017 11:00, Shivasharan S wrote: > > Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> > > Signed-off-by: Shiva

RE: [PATCH 03/39] megaraid_sas: raid 1 fast path code optimize

> > > > /** > > + * megasas_complete_r1_command - > > + * completes R1 FP write commands which has valid peer smid > > + * @instance: Adapter soft state > > + * @cmd_fusion:MPT command frame > > + * > > + */ > > +static inline void > >

RE: [PATCH] preview - block layer help to detect sequential IO

> Hi, Kashyap, > > I'm CC-ing Kent, seeing how this is his code. Hi Jeff and Kent, See my reply inline. > > Kashyap Desai <kashyap.de...@broadcom.com> writes: > > > Objective of this patch is - > > > > To move code used in bcache module in block

RE: [PATCH] preview - block layer help to detect sequential IO

> -Original Message- > From: kbuild test robot [mailto:l...@intel.com] > Sent: Thursday, January 12, 2017 1:18 AM > To: Kashyap Desai > Cc: kbuild-...@01.org; linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org; > ax...@kernel.dk; martin.peter...@oracle.com; j...@

[PATCH] preview - block layer help to detect sequential IO

off-by: Kashyap desai <kashyap.de...@broadcom.com> --- diff --git a/block/blk-core.c b/block/blk-core.c index 14d7c07..2e93d14 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -693,6 +693,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t gfp_mask, int node_id) { struct request

RE: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI commands to be retried

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Hannes Reinecke > Sent: Wednesday, December 14, 2016 9:07 PM > To: Sumit Saxena; linux-scsi > Subject: Re: SCSI: usage of DID_REQUEUE vs DID_RESET for returning SCSI >

RE: [PATCH] Update 3ware driver email addresses

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Martin K. Petersen > Sent: Thursday, December 08, 2016 4:43 AM > To: adam radford > Cc: linux-scsi; Kashyap Desai > Subject: Re: [PATCH] Upda

RE: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes

> -Original Message- > From: Tomas Henzl [mailto:the...@redhat.com] > Sent: Monday, November 21, 2016 9:27 PM > To: Kashyap Desai; Hannes Reinecke; Martin K. Petersen > Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- > s...@vger.kernel.org; Hannes Rein

RE: [PATCH][V2] scsi: megaraid-sas: fix spelling mistake of "outstanding"

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, November 30, 2016 12:50 AM > To: Colin King; Kashyap Desai; Sumit Saxena; Shivasharan S; James E . J . > Bottomley; Martin K . Petersen; megaraidlinux@broadcom.

RE: [PATCH 5/5] megaraid_sas: add mmio barrier after register writes

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Tomas Henzl > Sent: Friday, November 18, 2016 9:23 PM > To: Hannes Reinecke; Martin K. Petersen > Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- >

RE: [PATCH 4/5] megaraid_sas: scsi-mq support

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Hannes Reinecke > Sent: Friday, November 11, 2016 3:15 PM > To: Martin K. Petersen > Cc: Christoph Hellwig; James Bottomley; Sumit Saxena; linux- > s...@vger.kernel.org;

RE: [PATCH] hpsa: scsi-mq support

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig > Sent: Sunday, November 13, 2016 5:29 PM > To: Hannes Reinecke > Cc: Christoph Hellwig; Hannes Reinecke; Christoph Hellwig; Martin K. Petersen; > James

RE: [GIT PULL] SCSI fixes for 4.9-rc3

rnel.org > Subject: Re: [GIT PULL] SCSI fixes for 4.9-rc3 > > > > On 11.11.2016 04:30, Gabriel C wrote: > > > > On 05.11.2016 14:29, James Bottomley wrote: > > > > > > ... > > > >> Kashyap Desai (1): > >> scsi: megaraid_s

RE: Reduced latency is killing performance

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Jens Axboe > Sent: Thursday, November 10, 2016 10:18 PM > To: Hannes Reinecke; Christoph Hellwig > Cc: SCSI Mailing List; linux-bl...@vger.kernel.org > Subject: Re:

RE: [PATCH] Fix: scsi: megaraid: reduce the scope of pending-list lock to avoid double lock

> -Original Message- > From: i...@itu.dk [mailto:i...@itu.dk] > Sent: Monday, October 17, 2016 1:00 PM > To: Jiri Kosina > Cc: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley; Martin K. > Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kerne

RE: Delivery Status Notification for linuxr...@lsi.com

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Paul Menzel > Sent: Thursday, November 10, 2016 7:40 PM > To: Martin K. Petersen > Cc: linux-scsi@vger.kernel.org; James E.J. Bottomley > Subject: Re: Delivery Status

RE: [REGRESSION] 4.9-rc4+ doesn't boot on my test box

> -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Wednesday, November 09, 2016 6:50 AM > To: Kashyap Desai; Martin K. Petersen > Cc: linux-scsi > Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box > > On 11/08/2016 05:20

RE: [REGRESSION] 4.9-rc4+ doesn't boot on my test box

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Wednesday, November 09, 2016 4:45 AM > To: Jens Axboe > Cc: linux-scsi; Kashyap Desai; Martin K. Petersen > Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my test box > &

RE: Device or HBA level QD throttling creates randomness in sequetial workload

Read depth: 0 Write depth: 5 IO unplugs:79 Timer unplugs: 0 ` Kashyap > -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Monday, October 31, 2016 10:54 PM > To: Kashyap Desai; Omar San

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> -Original Message- > From: Omar Sandoval [mailto:osan...@osandov.com] > Sent: Monday, October 24, 2016 9:11 PM > To: Kashyap Desai > Cc: linux-scsi@vger.kernel.org; linux-ker...@vger.kernel.org; linux- > bl...@vger.kernel.org; ax...@kernel.dk; Christoph Hel

RE: Device or HBA level QD throttling creates randomness in sequetial workload

> > On Fri, Oct 21, 2016 at 05:43:35PM +0530, Kashyap Desai wrote: > > Hi - > > > > I found below conversation and it is on the same line as I wanted some > > input from mailing list. > > > > http://marc.info/?l=linux-kernel=147569860526197=2 > &

[PATCH v3 7/8] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map

CC: sta...@vger.kernel.org Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl --- drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH v3 6/8] MAINTAINERS: Update megaraid maintainers list

9117f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7612,12 +7612,12 @@ S: Maintained F: drivers/net/wireless/mediatek/mt7601u/ MEGARAID SCSI/SAS DRIVERS -M: Kashyap Desai <kashyap.de...@avagotech.com> -M: Sumit Saxena <sumit.sax...@avagotech.com> -M:

[PATCH v3 8/8] megaraid_sas: driver version upgrade

Signed-off-by: Sumit Saxena --- drivers/scsi/megaraid/megaraid_sas.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h index 43fd14f..74c7b44 100644 ---

[PATCH v3 1/8] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset

For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function)

[PATCH v3 4/8] megaraid_sas: Send SYNCHRONIZE_CACHE for non-raid to firmware

. CC: sta...@vger.kernel.org Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> Signed-off-by: Sumit Saxena <sumit.sax...@broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid

[PATCH v3 3/8] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach

This patch addresses the issue of driver firing DCMDs in PCI shutdown/detach path irrespective of firmware state. Driver will check for whether firmware is operational state or not before firing DCMDs. If firmware is in unrecoverbale state or does not become operational within specfied time,

[PATCH v3 5/8] megaraid_sas: Send SYNCHRONIZE_CACHE for VD to firmware

ESS ELSE Driver does not send SYNCH_CACHE command to the FW. Driver return SUCCESS for that command. ENDIF ENDIF ENDIF Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com> Signed-off-by: Sumit Saxena &

[PATCH v3 2/8] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade

This patch fixes the issue of wrong PhysArm was sent to firmware for R1 VD downgrade. Signed-off-by: Kiran Kumar Kasturi Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl

[PATCH v3 0/7] megaraid_sas: Updates for scsi-next

Changes in v3 two logical patches created for "Send SYNCHRONIZE_CACHE command to firmware" - Send SYNCHRONIZE_CACHE for JBOD to firmware - Send SYNCHRONIZE_CACHE for VD to firmware Changes in v2: 1. Removed unconditional msleep and moved calls to atomic_read into

RE: Device or HBA level QD throttling creates randomness in sequetial workload

workaround/alternative in latest upstream kernel, if user wants to see limited penalty for Sequential Work load on HDD ? ` Kashyap > -Original Message- > From: Kashyap Desai [mailto:kashyap.de...@broadcom.com] > Sent: Thursday, October 20, 2016 3:39 PM > To: linux-scsi@vge

RE: [PATCH v2 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware

for that command. > >ENDIF > > ENDIF > > ENDIF > > > > CC: sta...@vger.kernel.org > > Can you please split this into two, so we can backport the bug fix without > any of > the feature addition junk? James - I am sending new patch

Device or HBA level QD throttling creates randomness in sequetial workload

[ Apologize, if you find more than one instance of my email. Web based email client has some issue, so now trying git send mail.] Hi, I am doing some performance tuning in MR driver to understand how sdev queue depth and hba queue depth play role in IO submission from above layer. I have 24

Device or HBA level QD throttling creates randomness in sequetial workload

[ Apologize, if you find more than one instance of my email. Web based email client has some issue, so now trying git send mail.] Hi, I am doing some performance tuning in MR driver to understand how sdev queue depth and hba queue depth play role in IO submission from above layer. I have 24

RE: [PATCH] Fix: scsi: megaraid: reduce the scope of pending-list lock to avoid double lock

> -Original Message- > From: i...@itu.dk [mailto:i...@itu.dk] > Sent: Monday, October 17, 2016 1:00 PM > To: Jiri Kosina > Cc: Kashyap Desai; Sumit Saxena; Uday Lingala; James E.J. Bottomley; Martin K. > Petersen; megaraidlinux@avagotech.com; linux-scsi@vger.kerne

Device or HBA QD throttling creates holes in Sequential work load

[ Apologize, if this thread is reached to you multiple time ] Hi, I am doing some performance tuning in MR driver to understand how sdev queue depth and hba queue depth play role in IO submission from above layer. I have 24 JBOD connected to MR 12GB controller and I can see performance for 4K

  1   2   >