E1 speed is easy. Speed is about 4000 cells per second. I imagine that you
are developing an NDIS 5.0 device driver for Windows 98 or Windows 2000. I
think the Windows 2000 DDK has a sample driver which contains support for a
hardware SAR device. You can use this to determine generic interface issues
with NDIS. However, for doing the SAR functionality in software, here is
what I would do:
During MiniportInitialize, allocate an array of VC connection control
structures which will be used for each open VC connection. This connection
control block will have state variables, CRC32 accumulator, temporary
reassembly buffer[maximum_MTU+1 more cell buffer AAL5 Cell size], control
data required for sending packets. I would think that supporting 16-32
simultaneously open connections should be sufficient for E1. Since you will
need a temporary buffer of about 2k-16kbytes per connection, supporting 256
connections would require quite a bit of memory. Place this connection
control blocks in a free pool using a linked list or stack mechanism.
When Ndis calls your CoCreateVc you will need to get one of your free VC
control blocks described in the previous paragraph. Place this into an open
list of connections. Store the VPI/VCI from the CoCreateVc parameters into
the connection control block.
When Ndis calls your CoActivateVc you will need to find the connection from
the open list of connections and activate this connection. Merely a
semantic.
When Ndis calls your CoDeleteVc you will need to remove the connection from
the open list and place it into the free pool list.
When Ndis calls your CoDeactivateVc you will need to find the connection
from the open list of connections and deactivate this connection.
When you get an interrupt indicating that cells have been received, validate
the PTI field to be 0,1,2,3. If valid, then extract the VPI/VCI from the
cell header, use this and scan your list of open connections, if the VPI/VCI
matches, then copy the cell payload into your temporary buffer, accumulate
the data from the cell into the CRC32 accumulator, if the PTI is 1 or 3,
then this is the last cell. If the last cell, then validate the AAL5
trailer and verify that the CRC32 accumulator indicates a good frame. If
the frame is good, then indicate the frame to Ndis using
NdisMCoIndicateReceivePacket. If the cell is not the last cell, then
determine if the total cells received exceeds the maximum number of cells
for the MTU. If so then reset this connection control block to initial
state because you have max cells error. You do not want to overrun your
temporary buffer.
When Ndis calls your CoSendPackets, you must take the data received by this
function and use it to write cells to your hardware for transmission, set
the PTI field to 0 or 1 depending upon the current cell, accumulate CRC32,
pad out the last cell with 0s and write the appropriate AAL5 trailer.
Hope this helps.
Dominick
----- Original Message -----
From: “encarta”
To: “NT Developers Interest List”
Sent: Friday, February 25, 2000 8:47 AM
Subject: [ntdev] Re: Question about ATM miniport driver
> Hi,
>
> Thank you very much.
>
> Luckily our atm adapter is E1 2.048Mbps.
>
> I’m very appreciate your help. And any suggestion about write the SAR
>
> function is welcomed.
>
>
> xhcai
> xxxxx@sjtu.edu
>
> ÔÚ 00-2-24 6:51:00 you wrote£º
> >If your ATM adapter does not do SAR in hardware then you will have to
> >do the SAR functionality in the NDIS miniport driver. However, if your
ATM
> >adapter
> >supports a line interface which is faster than E3/DS3(34/45mbps), then
you
> >should stop
> >right now. You will be getting about 80000-100000 cells per second on a
> >fully
> >loaded link and you will absolutely not be able to do software SAR at
those
> >rates.
>
>
>
> ____________________________
> Free Email/SMTP/POP, http://www.bn3.com, Hosting xxxxx@yoursite.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@flashcom.net
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>