Is it possible for an NDIS miniport to call a DMA function, that can get an
estimate of the number of SG elements needed for a NetBuffer
before we call NdisMAllocateNetBufferSGList from the
MiniportSendNetBufferList handler. We want to know if we have adequate space
on out tx descriptor ring, and (if not) we’d place the NBL on a pending tx
list.
I know a function NdisQueryNetBufferPhysicalCount can provide the samilar
numbers, but I’ve found that the number wasn’t matched with the
SG list numbers sometimes.
Is it possible for an NDIS miniport to call a DMA function, that can
get an
estimate of the number of SG elements needed for a NetBuffer
before we call NdisMAllocateNetBufferSGList from the
MiniportSendNetBufferList handler. We want to know if we have adequate
space
on out tx descriptor ring, and (if not) we’d place the NBL on a
pending tx
list.
I know a function NdisQueryNetBufferPhysicalCount can provide the
samilar
numbers, but I’ve found that the number wasn’t matched with the
SG list numbers sometimes.
Any advice?
The sg list should be a maximum of the total number of pages in all the
buffers. To calculate it should be something like:
sg_size = 0
for each buffer in the list of chained buffers
sg_size += ADDRESS_AND_SIZE_TO_SPAN_PAGES(buffer va, buffer len)
If the pages for each buffer are physically contiguous then it may be
possible to describe them in a single sg entry but I’m not sure of that.
I think that the chance of the pages being physically contiguous is
going to be pretty low once the system has been up for a while so I
think that the above pseudocode is going to be sufficient.
You’d think that the SG list would only ever be a few entries at most
given a packet size of 1514, but once LSO comes into play then packet
sizes go up to around 64k in total, and if the TCP stream is made up of
a whole load of small sends then the SG list can actually get pretty
large
“James Harper” å†™å…¥æ¶ˆæ¯ news:xxxxx@ntdev… >> >> Is it possible for an NDIS miniport to call a DMA function, that can > get an >> estimate of the number of SG elements needed for a NetBuffer >> before we call NdisMAllocateNetBufferSGList from the >> MiniportSendNetBufferList handler. We want to know if we have adequate > space >> on out tx descriptor ring, and (if not) we’d place the NBL on a > pending tx >> list. >> >> I know a function NdisQueryNetBufferPhysicalCount can provide the > samilar >> numbers, but I’ve found that the number wasn’t matched with the >> SG list numbers sometimes. >> >> Any advice? >> > > The sg list should be a maximum of the total number of pages in all the > buffers. To calculate it should be something like: > > sg_size = 0 > for each buffer in the list of chained buffers > sg_size += ADDRESS_AND_SIZE_TO_SPAN_PAGES(buffer va, buffer len) > > If the pages for each buffer are physically contiguous then it may be > possible to describe them in a single sg entry but I’m not sure of that. > I think that the chance of the pages being physically contiguous is > going to be pretty low once the system has been up for a while so I > think that the above pseudocode is going to be sufficient. > > You’d think that the SG list would only ever be a few entries at most > given a packet size of 1514, but once LSO comes into play then packet > sizes go up to around 64k in total, and if the TCP stream is made up of > a whole load of small sends then the SG list can actually get pretty > large > > James > > > > Information from ESET NOD32 Antivirus, version of virus > signature database 4401 (20090906) > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > >
Information from ESET NOD32 Antivirus, version of virus signature database 4401 (20090906)