Lookahead buffer

Posted 2002.12.04 13:29
All messages from thread
Message 1 in thread
보낸 이:An Jung Sun (crete@garnets.com)
제목:What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/03


hi..
I want to know that meaning of "lookahead".
I am developing the NDIS driver....
Can anyone help me?
Message 2 in thread
보낸 이:David (qqqq@xxx.yyy.zzz)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/03


"An Jung Sun" <crete@garnets.com> writes:
>
> I want to know that meaning of "lookahead".
> I am developing the NDIS driver....
Packets come into a protocol (or intermediate) driver through one of two
callback routines.
In your ProtocolReceivePacket callback function, you are given a
complete packet.  If the routine completely handles the packet (or
rejects it), it should return zero - telling the lower-layer miniport
that it is OK to free the packet.  If it returns non-zero, then it is
telling NDIS that it needs to hold the packet for a while - the
lower-layer miniport will free the packet when NdisReturnPackets is
called that many times.  (eg. if you return 5, you must call
NdisReturnPackets 5 times.)
The ProtocolReceive callback doesn't work like this.  In
ProtocolReceive, you are not given an entire packet.  Instead, you get
the packet's header, and some of the packet's data, along with the size
of the complete packet.  The data you are given is the "lookahead"
buffer.  The header and lookahead buffers are freed as soon as
ProtocolReceive returns.
If the lookahead buffer contains the entire packet (if its size is equal
to the total size), then you have the entire packet.  If not, then you
must call NdisTransferData to get the rest of it.  Either way, if you
want to hold on to the data beyond the scope of the ProtocolReceive
callback, you must create a new packet from the header and data blocks
you are given.  When you're finished with your copy, just free it - you
don't tell the underlying miniport in this situation.
You must implement ProtocolReceive in your protocol driver.  You should
implement ProtocolReceivePacket as well, in order to improve
performance.
-- David
Message 3 in thread
보낸 이:Dean Henkel (henkel@us.ibm.com)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/18


David I pose this question to you because I'm sure you know the answer.
PacketRecievePacket will check to see if a pending ProtocolRecieve has
occurred. If it has, it will transfer the data. If not it throws it away.
My questions are:
How do I buffer the data in ProtocolRecievePacket if there is no outstanding
PacketReceiveIndicate call?
When the PacketlRecieiveIndicate call does occur how do I transfer this
buffered data into the user level buffer?
Would I be better off rejecting the packet even if it all is there, and
accepting it on a later PacketRead call?
If yes what if 2 packets come in, will the lower layer buffer them properly?
This driver is bound to a Ethernet and Token Ring driver. Everything works
except for the buffering of packets.
Here's the code snippet.
Thanks, hope you can help.
NTSTATUS
PacketRead(
    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP Irp
    )
{
    POPEN_INSTANCE      Open;
    PIO_STACK_LOCATION  IrpSp;
    PNDIS_PACKET        pPacket;
    NDIS_STATUS         Status;
    IF_LOUD(DbgPrint("Packet: Readn");)
    IrpSp = IoGetCurrentIrpStackLocation(Irp);
    Open=IrpSp->FileObject->FsContext;
    //
    //  See if the buffer is atleast big enough to hold the
    //  ethernet header
    //
    if (IrpSp->Parameters.Read.Length < ETHERNET_HEADER_LENGTH) {
        Irp->IoStatus.Status = STATUS_UNSUCCESSFUL;
        return STATUS_UNSUCCESSFUL;
    }
문서 전부 보기... (254줄 이상)

Message 4 in thread
보낸 이:David (qqqq@xxx.yyy.zzz)
제목:Re: What is a meaning of "Lookahead"?
뉴스 그룹:comp.os.ms-windows.programmer.nt.kernel-mode
View this article only
날짜:1998/08/19



Dean Henkel <henkel@us.ibm.com> writes:
>
> David I pose this question to you because I'm sure you know the
> answer.
Don't be so sure.  But we'll find out...
> PacketRecievePacket will check to see if a pending ProtocolRecieve has
> occurred. If it has, it will transfer the data. If not it throws it
> away.
What is "PacketRecievePacket"?  It's not an NDIS callback function, and
it's not in the code you posted.  I'll assume it's one of your
functions...
> My questions are:
> How do I buffer the data in ProtocolRecievePacket if there is no
> outstanding PacketReceiveIndicate call?
You're confused here.  ProtocolReceive and ProtocolReceivePacket are
never both called for a single packet.  One or the other, depending on
what the underlying miniport is using to indicate the packet to you.
If ProtocolReceivePacket is called, then you have the entire packet.  If
you return non-zero, then the packet will remain valid until you call
NdisReturnPackets.  If you return zero, the packet becomes invalid as
soon as the ProtocolReceivePacket function returns.
If ProtocolReceve is called, then you don't have a packet.  You have
some buffers (header and lookahead) that become invalid as soon as the
function returns.  If you want to hold on to the data beyond the scope
of the function, you must copy it to some other piece of memory.
There isn't a ways to look for outstanding indications.  Your callback
function(s) get called by NDIS when the underlying miniport indicates
packets to you.
> When the PacketlRecieiveIndicate call does occur how do I transfer
> this buffered data into the user level buffer?
I can't help you here.  I haven't written a protocol driver.  I'm
working with an intermediate driver.  I take the buffered data,
construct a new NDIS_PACKET, and indicate that data to the protocol
attached to my driver's upper-edge.
> Would I be better off rejecting the packet even if it all is there,
> and accepting it on a later PacketRead call?
If you reject it, it's gone.  It may be sent to some other protocol,

'Research > Network' 카테고리의 다른 글

How to enable IP Forwarding in Linux  (0) 2009.10.13
tcpdump sh4 cross-compile  (0) 2009.05.22
tcp packet을 받을때 커널의 흐름  (0) 2008.11.26
Network performance test  (0) 2005.09.20
TCP/IP 동영상  (0) 2002.12.04
Lookahead buffer  (0) 2002.12.04
« PREV : 1 : ··· : 476 : 477 : 478 : 479 : 480 : 481 : 482 : 483 : 484 : ··· : 537 : NEXT »