[nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport Win7/Win8

Alex Chang Alex.Chang at pmcs.com
Wed Aug 7 17:25:43 PDT 2013


Hi Dharani,

 

When you said  "it doesn't even enter into "if (pQI->NumSubIoQAllocated
< QueueID){}" statement.", which is not true. And you're right that
there will be one IO queue allocation attempt at least.

Looks like whenever any given queue is shared by multiple cores, you
need to set the flag to be ture.

 

Thanks,

Alex

 

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] 
Sent: Wednesday, August 07, 2013 5:16 PM
To: Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT
NOT VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport
Win7/Win8

 

Hi Alex. 

 

Comments in Green ...

 

Thanks,

Dharani.

________________________________

From: Alex Chang [Alex.Chang at pmcs.com]
Sent: Wednesday, August 07, 2013 5:06 PM
To: Dharani Kotte; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT
NOT VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport
Win7/Win8

Hi Dharani,

 

Please see my comments in red...

Thanks,

Alex

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] 
Sent: Wednesday, August 07, 2013 4:00 PM
To: Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT
NOT VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport
Win7/Win8

 

Hi Alex,

 

The situation was that when "pQI->NumSubIoQAllocFromAdapter" variable is
set to 1 which means that the controller want only 1 IO queue. In this
case it doesn't even enter into "if (pQI->NumSubIoQAllocated <
QueueID){}" statement.

If that's true, then there is no IO queue allocated at all, isn't it?

1 Queue is created but after that the Queue number will be forced to 1
and hence all the cores available are getting mapped to Queue 1.

 

But we need to use StartLocks when ever 2 or more cores shares the same
queue. The "fall back to use only one queue" case is covered only in the
situation where the NVMeAllocQueues() fails for the Queue, This
condition I didn't hit but you are right we may have to add this flag in
that condition as well.

 

drive formatting - If it is windows NTFS format I tested for Win8/Win7
32-bit.

IOMeter - I tested for Win8/Win7 32-bit

SDStress - I have not tested is it part of WHQL. Please test it if you
have chance. I don't have a WHQL setup right now, Can you pass the
SDStress exe if anything available with you.

SCSI compliance - I have not tested since I didn't touch any part of the
code that is related to SCSI Compliance but I can test it

 

Thanks,
Dharani.

 

From: Alex Chang [mailto:Alex.Chang at pmcs.com] 
Sent: Wednesday, August 07, 2013 3:46 PM
To: Dharani Kotte; nvmewin at lists.openfabrics.org
Subject: RE: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT
NOT VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport
Win7/Win8

 

Hi Dharani,

 

Sorry to take such long time to get back to you and thank you for the
effort.

I just finished reviewing your changes and noticed you added a flag
called "MultiplecoresToSingleQueueFlag". Does it mean there is only one
IO queue being allocated and shared by all the cores? If yes, then the
line you added (line#2828) in nvmeinit.c should be moved up to "fall
back to use only one queue" case. Let me know what you think.

By the way, have you tests it with drive formatting, IOMeter, SDStress
and SCSI compliance yet?

 

Thanks,
Alex

 

From: nvmewin-bounces at lists.openfabrics.org
[mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Dharani
Kotte
Sent: Wednesday, July 31, 2013 9:53 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** [WARNING - ENCRYPTED ATTACHMENT NOT
VIRUSSCANNED] OFA NVMe Windows driver contribution - 32-bitsupport
Win7/Win8

 

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: %%SENT_DATE%%
Subject: Suspect Message Quarantined 
 
 
 
WARNING: The virus scanner was unable to scan an attachment in an email
message sent to you.  This attachment could possibly contain viruses or
other malicious programs.  The attachment could not be scanned for the
following reasons:
 
%%DESC%%
 
The full message and the attachment have been stored in the quarantine.
 
The identifier for this message is '%%QID%%'.
 
Access the quarantine at: 
https://puremessage.pmc-sierra.bc.ca:28443/
 
For more information on PMC's Anti-Spam system:
http://pmc-intranet/wiki/index.php/Outlook:Anti-Spam_FAQ
 
IT Services
PureMessage Admin 
 

The attached is the code with 32-bit support tested on the Win7/Win8
32-bit systems. Please review it and let me know the comments.

 Password: sndk1234

Thanks,

Dharani.

 

From: Kwok Kong [mailto:Kwok.Kong at pmcs.com] 
Sent: Wednesday, July 31, 2013 9:29 AM
To: Dharani Kotte
Cc: Dave Landsman; Gurpreet Anand; Sumant Patro
Subject: RE: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] OFA NVMe
Windows driver contribution

 

Dharani,

 

This is great.

Would you please email it out to the following mailing list asking for
review and approval ?

 

nvmewin at lists.openfabrics.org

 

 

thanks

 

-Kwok

 

 

From: Dharani Kotte [mailto:Dharani.Kotte at sandisk.com] 
Sent: Wednesday, July 31, 2013 9:08 AM
To: Kong, Kwok (Kwok.Kong at idt.com); Kwok Kong
Cc: Dave Landsman; Gurpreet Anand; Sumant Patro
Subject: [WARNING - ENCRYPTED ATTACHMENT NOT VIRUS SCANNED] OFA NVMe
Windows driver contribution

 

 

Hi Kwok,

The attached is the code with 32-bit support tested on the Win7/Win8
32-bit systems. Can you please send it for review and let me know the
comments.

 

Password: sndk1234

Thanks,

Dharani.

 


-----Original Message-----
From: Kong, Kwok [mailto:Kwok.Kong at idt.com] 
Sent: Wednesday, June 26, 2013 12:58
To: Dave Landsman
Subject: OFA NVMe Windows driver contribution

Dave,

We are working on a NVMe Windows driver feature planning for the Dec
2013 release. Samsung cannot take on the task to get the driver to
support windows 32-bit systems.

I wonder if Sandisk can take on the task to get the driver to work in
Windows 32-bit system. 

It is much appreciated if Sandisk can take this task on.

Please let me know what you think.

Thanks

-Kwok

 

________________________________


PLEASE NOTE: The information contained in this electronic mail message
is intended only for the use of the designated recipient(s) named above.
If the reader of this message is not the intended recipient, you are
hereby notified that you have received this message in error and that
any review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify the sender by telephone or e-mail (as shown above)
immediately and destroy any and all copies of this message in your
possession (whether hard copies or electronically stored copies).













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130807/22c50a26/attachment.html>


More information about the nvmewin mailing list