[nvmewin] Q Pointer Reset After Learning Mode

[Chang, Alex]

Paul,

NVMeInitSubQueue and NVMeInitCplQueue are called in NVMeWaitOnSetupQueues, which is before we first create IO queues. After we delete the queue and re-create them, the pointers are not reset.

Thanks,
Alex
________________________________
From: Luse, Paul E [mailto:paul.e.luse at intel.com]
Sent: Tuesday, April 24, 2012 10:02 AM
To: Chang, Alex; nvmewin at lists.openfabrics.org
Subject: RE: Q Pointer Reset After Learning Mode

On item 1, it does.  Look in NVMeInitSubQueue() which is indeed called after we've learned. On item 2 I believe we discussed only checking this in DBG case because, once validated, it should work all of the time.  I'm not totally against a check in the free build as well but if it fails we'd need to set the error state for the driver because if our pending bit is set in this routine something really bad has happened.  We can talk about it in the review and if we agree to look at it in the free case I can check it in as part of this patch.

Thx
Paul

ULONG NVMeInitSubQueue(
    PNVME_DEVICE_EXTENSION pAE,
    USHORT QueueID
)
{
    PQUEUE_INFO pQI = &pAE->QueueInfo;
    PSUB_QUEUE_INFO pSQI = pQI->pSubQueueInfo + QueueID;
    PRES_MAPPING_TBL pRMT = &pAE->ResMapTbl;
    ULONG_PTR PtrTemp = 0;
    USHORT Entries;

    /* Ensure the QueueID is valid via the number of active cores in system */
    if (QueueID > pRMT->NumActiveCores)
        return ( STOR_STATUS_INVALID_PARAMETER );

    /* Initialize static fields of SUB_QUEUE_INFO structure */
    pSQI->SubQEntries = (QueueID != 0) ? pQI->NumIoQEntriesAllocated :
                                         pQI->NumAdQEntriesAllocated;
    pSQI->SubQueueID = QueueID;
    pSQI->FreeSubQEntries = pSQI->SubQEntries;
    pSQI->SubQTailPtr = 0;
    pSQI->SubQHeadPtr = 0;

From: Chang, Alex [mailto:Alex.Chang at idt.com]
Sent: Tuesday, April 24, 2012 9:56 AM
To: Luse, Paul E; nvmewin at lists.openfabrics.org
Subject: Q Pointer Reset After Learning Mode

Hi Paul,

I am afraid that I have couple more issues to report:
1. When the driver finishes core-vector map learning, it deletes all IO queues and re-creates them. However, the driver doesn't reset Submission Tail Pointer and Completion Head Pointer to 0, which causes an extra completion entry for each IO queue and other side effects.
2. In NVMeCompleteCmd, the driver asserts to check Pending bit and Context pointer of CMD_ENTRY (for Checked-built driver only). Free-built driver ignores the checking and insert the CMD_ENTRY back to freeQList, which corrupts the linked-list when the completion queue entry is not a valid one and gets added back to the freeQList TWICE. For example, an extra completion entry produced by issue#1 above.
I remember the original logic I put in was returning FALSE when it fails checking Pending bit and Context pointer and not touching the linked-list in the end of the routine.

Thanks,
Alex


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120424/3097abf7/attachment.html>