Yes, I believe fileio does, but trace out the syscall in the LXR, it may just map for kernel space memory.

Writes need to maintain sync as target must appear to be sync device. When you issue a write to RAIDCore your worker has to wait for the return from RAIDCore before it can return to the initiator.

Initiators expect that returns mean the data is to disk (well assume RAIDCore return means it's successfully to disk).

Take a look at blockio and how it handles async returns from block layer.

As far as memcpy goes is there no way to map the sglist to/from iovec?

You can look at how kernel devels handle that mapping in the source. Hit the LXR I'm sure you could dig up an example.

-Ross


----- Original Message -----
From: john M <johnmtp05@gmail.com>
To: Ross S. W. Walker
Cc: iscsitarget-devel@lists.sourceforge.net <iscsitarget-devel@lists.sourceforge.net>
Sent: Mon Jul 28 17:59:21 2008
Subject: Re: [Iscsitarget-devel] Integration with RAID Core

Ross,

Does the File-IO  copy the data-out pdu into the file using generic_file_write(which essantially is a memcpy ) ?

On Mon, Jul 28, 2008 at 2:03 PM, Ross S. W. Walker <RWalker@medallion.com> wrote:


        john M wrote:
        >
        > Hi Team,
        >
        > Can someone put some light on what might be going wrong?
       
       
        Can you put your code up?

 RAID Core core is IP of my comapny. i can't do that :(

       
       
        Would it have been easier/cleaner to create a RAIDCore
        io type and not messed around with the iscsi processing?


 I have written the interface which converts the iSCSI Command to RAID Core io type.  The Reads are working fine, so are writes also for a particular amount of time.  After that it doesn't :(.  
 I have a interface layer between the IET and RAID Core which would have registered itself with RAID Core and also registers itself as RAID IO type with IET.  The interface gets a write command, which is given to RAID Core.  The RAID Core comes back(Asynchronously) after processing the write command with the SGL List which can be filled(DMA'ed) for the write request.  Currently i am doing MEMCPY(As i am not having any DMA Engine on my mother board/NIC).  It works for a while after that IET starts getting Task Managemnt commands.  Which i suspect because of MEMCPY(Which eats up the processor time).
My Question is Can i DO MEMCPY ?
if yes what are the sizes for which i can do MEMCPY ?  (As for 512 Bytes write, i am seeing this scenerio )
I see that, in  IET whenever the worker thread picks up the write command, it does a FILE WRITE and creats the  response PDU and queues the respose PDU into the send queue(Everyhting happens synchronously).  Whereas in my case the worker thread pick up the PDU and gives it to RAID CORE and returns.  After a while in another thread context(RAID CORE thread context) the response is created and the respose PDU is queued into the response queue.  Does this affect the PROTOCOL PROCESSING?


       
       
        If you had, then it could have been extended to work with
        different generic scsi devices...
       
        How many initiators?

1 Initiator only

        How many writes per initiator?

512 Bytes write

        What is your ietd.conf settings. The 1800 writes may represent
        total writes outstanding and your RAIDCore or code is
        not sending back any responses, or the correct responses.

I see the response on the wireshark which looks fine.  Please find the attached wireshark output.

       
       
        -Ross
       
        ______________________________________________________________________
        This e-mail, and any attachments thereto, is intended only for use by
        the addressee(s) named herein and may contain legally privileged
        and/or confidential information. If you are not the intended recipient
        of this e-mail, you are hereby notified that any dissemination,
        distribution or copying of this e-mail, and any attachments thereto,
        is strictly prohibited. If you have received this e-mail in error,
        please immediately notify the sender and permanently delete the
        original and any copy or printout thereof.
       
       



This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.