I have developed an protocol driver in which at the receiving end im loosing certain frames at the miniport level.Im planning to implement the flow control in a following way.
Check for the available buffer at the receving end miniport ,based on that value send the packets from send side.
Im yet to figure out the OID used to Query the free buffer in the minport.
Could you please give me your suggestions on the above approach.Is there any better way of acheiving the flow control.
From: xxxxx@lists.osr.com [mailto:bounce-299896- xxxxx@lists.osr.com] On Behalf Of xxxxx@wipro.com
Sent: Sunday, September 09, 2007 7:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Ndsi Protocol Driver Flow Control
Hi,
I have developed an protocol driver in which at the receiving
end im loosing certain frames at the miniport level.Im planning to
implement the flow control in a following way.
Check for the available buffer at the receving end miniport ,based on
that value send the packets from send side.
Im yet to figure out the OID used to Query the free buffer in the
minport.
[PCAUSA] AFAIK there is no OID to query resources.
Could you please give me your suggestions on the above approach.Is
there any better way of acheiving the flow control.
[PCAUSA] Study protocols like TCP/IP to understand how they implement flow control.
Study why you are losing packets. Are you actually losing packets because you can’t allocate buffers or memory? Or, is it because of some other reason.
Do you know what point in your data path is the bottleneck? Spend time on the slowest part of your data path before adding memory.
Your proposal will not work as you expect. You could have plenty of host receive buffer available at the time the chip is not keeping up. Any packet on the wire needs to travel at least 3 or 4 clock domains on most modern NIC before it makes it to the host bus I/F. There are different kind of buffering mechanism such FIFO, on-chip, offchip static memory between domains. When one or more domain is under backpressure that would cause packets to be dropped, the state machine within the MAC will send IEEE pause frames to the sender to back off if flow control is enabled and had been negotiated with link partner–usually a Ethernet switch. You don’t get FC on a hub even you enable flow control on the NIC.
You first want to check the NIC’s advanced property page to see if FC is enabled, you also want to check that FC is enabled on all switch ports (switch can run out of buffer too) and all stations. However, the hw FC still doesn’t guarantee packet delivery, that’s why L4 Reliable Transport Service (send/ack/resend) like TCP came into the picture.
Hope that helps,
Calvin Guan
Principal Engineer
Broadcom Corporation
Connecting Everything(r)
wrote in message news:xxxxx@ntdev… > Hi, > > I have developed an protocol driver in which at the receiving end im loosing certain frames at the miniport level.Im planning to implement the flow control in a following way. > > Check for the available buffer at the receving end miniport ,based on that value send the packets from send side. > > Im yet to figure out the OID used to Query the free buffer in the minport. > > Could you please give me your suggestions on the above approach.Is there any better way of acheiving the flow control. > > Thanks > Alex. >
> I have developed an protocol driver in which at the receiving end im loosing certain frames
at the miniport level.
How can a *protocol* possibly lose packets at the miniport level??? Certainly, it may well happen that some packets get lost on the way for this or that reason, but it has nothing to do with your protocol - as far as your protocol driver is concerned, there is just no data receipt unless data gets indicated to it. Therefore, if you need guaranteed delivery, you just have to introduce TCP-like acknowledgement logic into your protocol.
Certainly, if you mean that it is your protocol who loses packets that have been indicated to it…
well, then this is a very different story…