X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C76A7F.37E1567E@onstor-exch02.onstor.net>; Mon, 19 Mar 2007 16:35:03 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C76A7F.37E1567E"
Content-class: urn:content-classes:message
Subject: Cougar FC/SCSI design
Date: Mon, 19 Mar 2007 16:35:02 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02E40303@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cougar FC/SCSI design
Thread-Index: AcdqfzeKr0qlecjORgOqBlHxk+5Ncg==
From: "Bill Nadzam" <bill.nadzam@onstor.com>
To: "dl-Cougar" <dl-Cougar@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76A7F.37E1567E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Preface:
=20
    This design spec is in free form for now. Will move into a formal
document ASAP.
=20
Information:

*	The Cougar Hardware platform forces the FCNIM to share CPU Cores
with FPNIM. One task which I am not sure how to do, is to create a
thread on the FPNIM. This "Thread" will be responsible for a single FC
Port, or QLogic FC Core. Remember the QLogic parts being used are Dual
core. Each core is a totally separate hardware part from the other. In
the simplest form Cougar will have four of these threads running. One
for each FC port or core. In theory these threads should be able to run
on any CPU core. In essence a simple approach to MP the operations now
done. Starting the thread will lock the resources associated with that
FC port.
*	The FCNIM does not seem to have any form of RMC? Is this true?
Its compiled in, but James K. tells me its not usable. RMC, or reliable
message system is used in the FCNIM today, and must be there for SSC
<to> FC communications.=20
*	Since the FCNIM requires the use of RMC. There will be a
requirement to get RMC onto the FPNIM for use by the FC thread. With RMC
is in place, communications from EVM-SERVER can be done using RMC
protocol. Using RMC to send data service requests to the FC thread.
Although this is not the best use of the our flat memory system, this
will give the ability to read/write through the machine.=20
*	The nice part about using this system, is nothing else need
change. All of the eDesc flags can be maintained. Only the transfer path
changes, and in this case, there is no real transfer. Just a simple move
of the data via RMC. The key is to get RMC up and usable with evm-server
<to/from> scsi. SCSI command responses will be via the accept session
created by the open.
*	Inside sm-evm-srvr/evm-msg.c routine evm_sendScsiMsg( ); also
evm_sendSbmScsiWriteMsg( ); can be changed to transport via RMC open
session.  It might be best to replace this file with a Cougar only
version of evm-msg-cougar.c.....

Better method:

*	Change the file system requests. Now all requests are either one
or eight kilobytes at a time. Each request is formed by a separate
descriptor. This needs to change. The FC hardware can run at a higher
efficiency when larger block transfers can take place. This is not to
say that all read/write operations be done in a single command. This is
not possible either. The better approach would be to request something
close to thirty two kilobytes at a time when needed. Maybe having some
knobs to test with. A push off system is also good, where the first
request for sequential data starts out as a set of commands.=20
*	The best use of memory for reading to or writing from is
contiguous space, This is not practical, so if needed the use of eight
kilobyte chunks can still be used. A list of data pointers, and data
lengths would be an excellent system, as that can be copied directly
into the QLogic control blocks.

		The Qlogic IOCB "Input Output Control Block" use a
simple structure for data pointers.
		    {
		        uint64    pointerToDataBuffer;
		        uint32    Data_Length;
		    };

This is a working document:

*	First cut at getting data through to the FC.
	March 19, 2007


------_=_NextPart_001_01C76A7F.37E1567E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D753275021-19032007>Preface:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D753275021-19032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>&nbsp;&nbsp;&nbsp;=20
This design spec is in free form for now. Will move into a formal =
document=20
ASAP.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D753275021-19032007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D753275021-19032007>Information:</SPAN></FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D753275021-19032007>The =
Cougar Hardware=20
  platform forces the FCNIM to share CPU Cores with FPNIM. One task =
which I am=20
  not sure how to do, is to create a thread on the FPNIM. This "Thread" =
will be=20
  responsible for a single FC Port, or QLogic FC Core. Remember the =
QLogic parts=20
  being used are Dual core. Each core is a totally separate hardware =
part from=20
  the other. In the simplest form Cougar will have four of these threads =

  running. One for each FC port or core. In theory these threads should =
be able=20
  to run on any CPU core. In essence a simple approach to MP the =
operations now=20
  done. Starting the thread will lock the resources associated with that =
FC=20
  port.</SPAN></FONT></LI>
  <LI><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007></SPAN></FONT><FONT=20
  face=3DArial size=3D2><SPAN class=3D753275021-19032007>The FCNIM does =
not seem to=20
  have any form of RMC? Is this true? Its compiled in, but James =
K.&nbsp;tells=20
  me its not usable. RMC, or reliable message system is used in the =
FCNIM today,=20
  and must be there for SSC &lt;to&gt; FC communications. =
</SPAN></FONT></LI>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D753275021-19032007>Since =
the FCNIM=20
  requires the use of RMC. There will be a requirement to get RMC onto =
the FPNIM=20
  for use by the FC thread. With RMC is in place, communications from =
EVM-SERVER=20
  can be done using RMC protocol. Using RMC to send data service =
requests to the=20
  FC thread. Although this is not the best use of the our flat memory =
system,=20
  this will&nbsp;give the ability to read/write through the machine.=20
  </SPAN></FONT></LI>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D753275021-19032007>The =
nice part about=20
  using this system, is nothing else need change. All of the eDesc flags =
can be=20
  maintained. Only the transfer path changes, and in this case, there is =
no real=20
  transfer. Just a simple move of the data via RMC. The key is to get =
RMC up and=20
  usable with evm-server &lt;to/from&gt; scsi. SCSI command responses =
will be=20
  via the accept session created by the open.</SPAN></FONT></LI>
  <LI><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>Inside=20
  sm-evm-srvr/evm-msg.c routine evm_sendScsiMsg( ); also=20
  evm_sendSbmScsiWriteMsg( ); can be changed to transport via RMC open=20
  session.&nbsp; It might be best to replace this file with a Cougar =
only=20
  version of evm-msg-cougar.c.....</SPAN></FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D753275021-19032007>Better =

method:</SPAN></FONT></DIV>
<UL>
  <LI><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>Change the file=20
  system requests. Now all requests are either one or eight kilobytes at =
a time.=20
  Each request is formed by a separate descriptor. This needs to change. =
The FC=20
  hardware can run at a higher efficiency when larger block transfers =
can take=20
  place. This is not to say that all read/write operations be done in a =
single=20
  command. This is not possible either. The better approach would be to =
request=20
  something close to thirty two kilobytes at a time when needed. Maybe =
having=20
  some knobs to test with. A push off system is also good, where the =
first=20
  request for sequential data starts out as a set of commands.=20
  </SPAN></FONT></LI>
  <LI><FONT face=3DArial size=3D2><SPAN class=3D753275021-19032007>The =
best use of=20
  memory for reading to or writing from is contiguous space, This is not =

  practical, so if needed the use of eight kilobyte chunks can still be =
used. A=20
  list of data pointers, and data lengths would be an excellent system, =
as that=20
  can be copied directly into the QLogic control =
blocks.</SPAN></FONT></LI></UL>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>The Qlogic IOCB=20
    "Input Output Control Block" use a simple structure for data=20
    pointers.</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D753275021-19032007>&nbsp;&nbsp;&nbsp; {</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    =
class=3D753275021-19032007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    uint64&nbsp;&nbsp;&nbsp; pointerToDataBuffer;</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    =
class=3D753275021-19032007>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    uint32&nbsp;&nbsp;&nbsp; Data_Length;</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2><SPAN=20
    class=3D753275021-19032007>&nbsp;&nbsp;&nbsp;=20
};</SPAN></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>This is a=20
working document:</SPAN></FONT></DIV>
<UL>
  <LI dir=3Dltr><FONT face=3DArial size=3D2><SPAN =
class=3D753275021-19032007>First cut=20
  at getting data through to the FC.<BR>March 19,=20
2007</SPAN></FONT></LI></UL></BODY></HTML>

------_=_NextPart_001_01C76A7F.37E1567E--
