At 11:25 AM 2/10/2001 +0300, you wrote:
> chance of more than about 35 MBytes/sec or so. As NDIS requires every
> packet to be copied,
Are you sure in this?
>From what I know on NDIS, one can easily attach any MDL (or partial MDL) as
a tail of the network packet and transmit it without any memcpy in between.
The receive works in the similar way - the NIC’s driver copies the packet
data (possibly by DMA) to the MDL chain provided by the protocol driver.
I’m not absolutely positive, as it’s been a couple of years since I worked
on an NDIS driver. For the specific processor/chipset involved, this could
be a very serious bottleneck. I had discussed the problem with Microsoft
while Win2000 was in development, and they agreed it was a real problem.
They said it would be fixed in Win2000, but I didn’t offhand see how it was
fixed when the Win2000 DDK came out.
For transmitting a packet, no copy is needed. For receiving a packet, it is
technically possible (at least in NT 4) to avoid the copy much of the time.
In reality, the overhead of indicating a single packet header up to the
protocol, getting a callback to start the transfer of the rest of the
packet, and then eventually indicating the completion of the transfer, is
more overhead than copying the packet. This is especially true now with the
Pentium 4, as it’s memory copy performance is 650 MBytes/sec.
A typical NDIS driver will get an interrupt when a bunch of packets have
been DMA’d into temporary buffers. A bunch of these packets will get passed
up to the protocol, where it figures out which virtual circuit they belong
to and copies the bytes from into either the application buffer or protocol
stream buffer if no application buffer is currently available. The packet
buffers then get recycled and put back on the hardware free buffer list.
For a fast network device (gigethernet and fibre channel are around 100
MBytes/sec), and a slow memory copy processor (the Pentium 4 is about 650
MBytes/sec, the Pentium 3 is about 135 MByte/sec, the older Pentiums were
down around 35 MBytes/sec), this is not such a good architecture.
I believe there also now is a LAN card that runs TCP/IP in the firmware. I
assume this would no longer be called an NDIS device though. I also assume
it’s often able to eliminate the copy because the user buffer physical
addresses would get passed down into the device. The hardware can then do
the TCP stream reassembly.
As a note, ATM adapters I believe have always done the virtual circuit
stream reassembly in hardware, so have delivered received data directly
into the application buffer.
I also know that some fibre channel adapters are not so flexible about
their alignment requirements for data they DMA. One basic requirement of
avoiding copying received network data is the hardware has to be willing to
DMA to arbitrary byte addresses. This is caused by the network header and
the fact that stream packets can be broken on arbitrary byte boundaries.
SCSI like disk transfers on the other hand, are generally very well
aligned, like on sector boundaries.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com