Niranjan,
Some IM drivers allocate an entirely new buffer (or list of buffers) from
non-paged pool, some may be clever enough (and architected to deal with)
simply ‘re-describing’ the portions of the existing packet buffer chain (MDL
chain) with new NDIS_BUFFERs to eliminate copying.
As Thomas has indicated, the receive path is often more restrictive than the
send path since minimum look-a-head must be maintained and ultimately
TCPIP.SYS expects that the first NDIS_BUFFER (MDL) contains the entire MAC
and IP (and TCP/UDP) header.
And yes, when I said create new packet that meant a new NDIS_PACKET (from a
packet pool managed by your driver), non-paged pool to actually store the
data, and NDIS_BUFFERs allocated by your driver to describe the NP-pool
buffer and chained to the NDIS_PACKET. Once you are going to copy the data,
trying to optimize away the allocation of an NDIS_PACKET is often ‘small
change’ compared to the overall operation and simply makes your driver much
harder to understand and debug.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niranjan
Sent: Wednesday, August 17, 2005 4:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS Intermediate Driver - Adding new header
Does IM driver copies the data or it just allocate and initialize a new
packet descriptor and then chain the existing buffer descriptor (received
from the upper layer having packet data) to the new packet descriptor. IM
driver doesn’t allocate any buffer (using NdisAllocateBuffer) to copy the
data received from the upper layer or lower layer.
Also, when you say to create a new packet at intermediary layer, it means to
create NDIS buffer first (using NdisAllocateBuffer from the buffer pool) and
then set the private field of NDIS packet with this buffer, not just
allocating and initializing a new packet descriptor.
I am new to NDIS programming, so these question might be very naive. Thanks
for all your help.
Best Regards,
-Niranjan
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Niranjan,
>
> If you are going to copy the data, you will need to allocate a new
> NDIS_PACKET. In fact, most of the time your IM driver passes a received
> NDIS_PACKT ‘up’ or a sent NDIS_PACKET ‘down’ it will need to allocate a
new
> packet. The exception is if you have used the “Packet Stack” mechanism.
> Even with “packet stacking” you will need to deal with the possibility
that
> the packet stack is exhausted and allocate a new NDIS_PACKET anyway.
>
> I recommend you read the DDK section on packet handling for IM drivers
very
> carefully and take advantage of the resources at www.ndis.com /
> www.pcausa.com which address packet handling.
>
> Now your specific scenarios:
>
> 1. You mean changing the data in the buffer right? You must allocate a
new
> buffer and a new NDIS_PACKET to reference the NDIS_BUFFER chain (MDL
chain).
> Essentially, you must copy the packet. It may be possible to use a packet
> stack approach here and avoid the new NDIS_PACKET but frankly I have not
> ever tried and I don’t recommend it.
>
> 2. Same as above. You changed the data and the ‘description’ of the
> buffers.
>
> 3. If a packet stack is available, you can add the new header although in
> practice the benefit of not performing the copy may be thwarted by other
> rules you must follow. The NDIS_PACKET, most particularly the NDIS_BUFFER
> chain, must be restored to the original state before you can return the
> packet to the owner (the protocol that sent it or the NIC that).
>
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Niranjan
> Sent: Wednesday, August 17, 2005 11:45 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] NDIS Intermediate Driver - Adding new header
>
> There are three cases of updating/chaging a NDIS packet:
>
> 1. Updating NDIS packet data without any change in the length of the
packet.
>
> 2. Updating NDIS packet data where the length of the packet changes
>
> 3. Adding a entirely new header at the beginning of the received NDIS
packet
> (no changes in the existing packet data, just addition of few more bytes)
>
> For case 1, I am not sure whether we need to allocate a new NDIS packet or
> we can just change the data in the NDIS buffer as it doesn’t require any
> memory allocation.
>
> For case 2, we need to allocate a new NDIS packet.
>
> But for case 3, do I need to allocate a new packet or just a new NDIS
> buffer. I was thinking of allocating a new NDIS buffer which can hold the
> new intermediary layer header information and then link this buffer to the
> head of the buffer-descriptor chain attached to a packet descriptor (using
> NdisChainBufferAtFront). This will not require unnecessary copy of
original
> packet payload. Please let me know whether this is correct design or not.
>
> Best Regards,
>
> -Niranjan
>
>
>
> “Beyers Cronje” wrote in message news:xxxxx@ntdev…
> Hi Thomas,
>
> I was under the impression that one can change data allocated by
> tcp/ip, e.g. changing the destination IP address, without having to
> allocate your own packet and buffer descriptors. Am I wrong in this ?
> Obviously this involves handling checksum and TCP task offload issues.
>
> On the other hand, adding additional data such as Niranjan described
> requires the copy and allocation of your own packet and buffer
> descriptors ?
>
> Regards
>
> Beyers Cronje
>
> On 8/16/05, Thomas F. Divine wrote:
> >
> >
> >
> > “Niranjan” wrote in message
news:xxxxx@ntdev…
> >
> >
> > Hi,
> >
> >
> >
> > I am designing a new layer between TCP/IP and MAC layer using NDIS
> > intermediate drivers (PassThru samples) on Windows CE 5.0. The new layer
> has
> > its own header and few control packets. I wanted to know whether it is
> > possible to change the packet structure in this intermediate driver
> > (PassThru drivers) or not. Also, whether this is a good design or not.
If
> > not, what are the other ways in which I can implement this middle layer
> > between TCP/IP and MAC layer?
> >
> >
> >
> > NDIS IM drivers seem to be a good choice.
> >
> >
> >
> >
> > I am confused because at many places, it suggests not to modify packet
> data
> > virtual memory or buffer descriptor at the intermediate drivers if you
> > haven’t allocated it.
> >
> >
> >
> > This is not a suggestion. If you didn’t allocate the VM, then you should
> not
> > change or modify it. You must invent a method that inserts your header
> > without modifying other VM or other NDIS buffer descriptors.
> >
> >
> >
> > The simplest approach is to allocate your own VM sufficiently large to
> > accomodate the original packet plus your header. Copy the MAC header,
your
> > header and then the original packet payload into your own VM. Then
> allocate
> > your own NDIS buffer and packet descriptor and send that instead of the
> > original.
> >
> >
> >
> > If you get more experiance with the idea behind NDIS buffer descriptors
> and
> > memory descriptor lists you may see a method that involves less copying.
> >
> >
> >
> > Thomas F. Divine
> >
> >
> >
> >
> >
> > I will greatly appreciate any help in this regard. Thanks in advance.
> >
> >
> >
> > Best Regards,
> >
> > -Niranjan
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@msn.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@msn.com
To unsubscribe send a blank email to xxxxx@lists.osr.com