Prev: EWT and Logman.exe for dummies
Next: How to detect the mouse horizontal scroll?
From: Peter on 16 Apr 2008 21:01
Hi!

My understanding of how protocols/IM drivers parse indicated rx NBLs/NBs is
by accessing the data starting at NET_BUFFER_CURRENT_MDL(NB) and offset by
NET_BUFFER_CURRENT_MDL_OFFSET(NB).

Our miniport driver will occasionally shift the offset within the
NET_BUFFER_CURRENT_MDL(NB) and will set NET_BUFFER_CURRENT_MDL_OFFSET(NB)
appropriately. Unfortunately, the NDIS 6.5 offloadchecksum test fails and
reports data corruption because it is not taking the
NET_BUFFER_CURRENT_MDL_OFFSET(NB) into consideration. I have verified this
by looking at the MDL it reports as containing corrupted data. In all cases,
the test is looking at data at MDL->MappedSystemVa without offsetting this
by the NET_BUFFER_CURRENT_MDL_OFFSET.

Note that this is the only test that fails. All other tests, such as
offloadlso, works.

Is this a known problem with the NDIS 6.2/NDIS.Net that comes with DTM 1.2?

Thanks!


From: Alireza Dabagh [MS] on 17 Apr 2008 02:21
Peter, you should use NDIS APIs to move these data offsets
(NdisAdvance/RetreatNetBuffer(List)DataStart). Otherwise NB->MdlChain +
NB->DataOffset will not be consistent with NB->CurrentMdl and
NB->CurrentMdlOffset.

NDIS assumes the first MDL in the NB and the NB->DataOffset fields are
always correct while the NB->CurrentMdl and NB->CurrentMdlOffset fields may
be uninitialized. As a result, NDIS in some API calls may recalculates these
fields based on the value of NB->MdlChain and NB->DataOffset and in the
process overrides your modification to CurrentMdl and CurrentMdlOffset.

What you are doing leads to data corruption and by the time you get the NBL
back, CurrentMdl and CurrentMdlOffset might not be what you set them to.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Peter" <x@y> wrote in message
news:%23MVg7bCoIHA.4848(a)TK2MSFTNGP05.phx.gbl...
> Hi!
>
> My understanding of how protocols/IM drivers parse indicated rx NBLs/NBs
> is by accessing the data starting at NET_BUFFER_CURRENT_MDL(NB) and offset
> by NET_BUFFER_CURRENT_MDL_OFFSET(NB).
>
> Our miniport driver will occasionally shift the offset within the
> NET_BUFFER_CURRENT_MDL(NB) and will set NET_BUFFER_CURRENT_MDL_OFFSET(NB)
> appropriately. Unfortunately, the NDIS 6.5 offloadchecksum test fails and
> reports data corruption because it is not taking the
> NET_BUFFER_CURRENT_MDL_OFFSET(NB) into consideration. I have verified this
> by looking at the MDL it reports as containing corrupted data. In all
> cases, the test is looking at data at MDL->MappedSystemVa without
> offsetting this by the NET_BUFFER_CURRENT_MDL_OFFSET.
>
> Note that this is the only test that fails. All other tests, such as
> offloadlso, works.
>
> Is this a known problem with the NDIS 6.2/NDIS.Net that comes with DTM
> 1.2?
>
> Thanks!
>
>

From: Peter on 17 Apr 2008 03:04
Ali, thanks again for the quick response.

However, my concern in bringing this up was in code optimization. I'm aware
of the NdisAdvance/RetreatNetBuffer(List)DataStart) calls, but I felt it was
easier (and more optimal) to just set NB->CurrentMdlOffset (a macro) rather
than call the NdisRetreatNetBufferStart function.

Since this is an issue in how the NDIS 6.x miniport sets up the NBL/NB for
receive indications, and since my miniport uses a single buffer (i.e.,
single MDL) referenced through a single NB, can I assume that I can avoid a
function call by just correctly setting NET_BUFFER_DATA_OFFSET(NB) instead
of NET_BUFFER_CURRENT_MDL_OFFSET(NB)?

Also, under what conditions should an NDIS 6.x miniport use
NET_BUFFER_CURRENT_MDL_OFFSET(NB)? It appears that the miniport should not
use this when preparing an NB for an rx indication, and it seems that the
miniport should use this in its MiniportSGList function. However, are there
other criterias to keep in mind when using this MACRO?

Thanks!

"Alireza Dabagh [MS]" <alid(a)online.microsoft.com> wrote in message
news:u$%23vINFoIHA.1236(a)TK2MSFTNGP02.phx.gbl...
> Peter, you should use NDIS APIs to move these data offsets
> (NdisAdvance/RetreatNetBuffer(List)DataStart). Otherwise NB->MdlChain +
> NB->DataOffset will not be consistent with NB->CurrentMdl and
> NB->CurrentMdlOffset.
>
> NDIS assumes the first MDL in the NB and the NB->DataOffset fields are
> always correct while the NB->CurrentMdl and NB->CurrentMdlOffset fields
> may be uninitialized. As a result, NDIS in some API calls may recalculates
> these fields based on the value of NB->MdlChain and NB->DataOffset and in
> the process overrides your modification to CurrentMdl and
> CurrentMdlOffset.
>
> What you are doing leads to data corruption and by the time you get the
> NBL back, CurrentMdl and CurrentMdlOffset might not be what you set them
> to.
>
> -ali
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Peter" <x@y> wrote in message
> news:%23MVg7bCoIHA.4848(a)TK2MSFTNGP05.phx.gbl...
>> Hi!
>>
>> My understanding of how protocols/IM drivers parse indicated rx NBLs/NBs
>> is by accessing the data starting at NET_BUFFER_CURRENT_MDL(NB) and
>> offset by NET_BUFFER_CURRENT_MDL_OFFSET(NB).
>>
>> Our miniport driver will occasionally shift the offset within the
>> NET_BUFFER_CURRENT_MDL(NB) and will set NET_BUFFER_CURRENT_MDL_OFFSET(NB)
>> appropriately. Unfortunately, the NDIS 6.5 offloadchecksum test fails and
>> reports data corruption because it is not taking the
>> NET_BUFFER_CURRENT_MDL_OFFSET(NB) into consideration. I have verified
>> this by looking at the MDL it reports as containing corrupted data. In
>> all cases, the test is looking at data at MDL->MappedSystemVa without
>> offsetting this by the NET_BUFFER_CURRENT_MDL_OFFSET.
>>
>> Note that this is the only test that fails. All other tests, such as
>> offloadlso, works.
>>
>> Is this a known problem with the NDIS 6.2/NDIS.Net that comes with DTM
>> 1.2?
>>
>> Thanks!
>>
>>
>


From: Alireza Dabagh [MS] on 17 Apr 2008 03:31
> Since this is an issue in how the NDIS 6.x miniport sets up the NBL/NB for
> receive indications, and since my miniport uses a single buffer (i.e.,
> single MDL) referenced through a single NB, can I assume that I can avoid
> a function call by just correctly setting NET_BUFFER_DATA_OFFSET(NB)
> instead of NET_BUFFER_CURRENT_MDL_OFFSET(NB)?

You need to change all of the following fields together:
NB->DataOffset (increment it by delta)
NB->DataLength (-decrement- it by delta)
NB->CurrentMdlOffset (increment it by delta)

This is assuming you know you are not going beyond the first MDL and first
and CurrentMdl are the same. NdisAdvanceNetBufferDataStart does all this for
you and is not as expensive as you think.

> Also, under what conditions should an NDIS 6.x miniport use
> NET_BUFFER_CURRENT_MDL_OFFSET(NB)? It appears that the miniport should not
> use this when preparing an NB for an rx indication, and it seems that the
> miniport should use this in its MiniportSGList function. However, are
> there other criterias to keep in mind when using this MACRO?

CurrentMdl and CurrentMdlOffset are really there for optimization so we
don't have to walk the MDL chain on NET_BUFFER for DataOffset bytes to get
to the begging of the real (in use) data if we have already done
so.CURRENT_MDL macros are for reading the current MDL and offset and not for
setting them.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Peter" <ImInSoquel(a)nospam.nospam> wrote in message
news:OsQl3kFoIHA.1036(a)TK2MSFTNGP03.phx.gbl...
> Ali, thanks again for the quick response.
>
> However, my concern in bringing this up was in code optimization. I'm
> aware of the NdisAdvance/RetreatNetBuffer(List)DataStart) calls, but I
> felt it was easier (and more optimal) to just set NB->CurrentMdlOffset (a
> macro) rather than call the NdisRetreatNetBufferStart function.
>
> Since this is an issue in how the NDIS 6.x miniport sets up the NBL/NB for
> receive indications, and since my miniport uses a single buffer (i.e.,
> single MDL) referenced through a single NB, can I assume that I can avoid
> a function call by just correctly setting NET_BUFFER_DATA_OFFSET(NB)
> instead of NET_BUFFER_CURRENT_MDL_OFFSET(NB)?
>
> Also, under what conditions should an NDIS 6.x miniport use
> NET_BUFFER_CURRENT_MDL_OFFSET(NB)? It appears that the miniport should not
> use this when preparing an NB for an rx indication, and it seems that the
> miniport should use this in its MiniportSGList function. However, are
> there other criterias to keep in mind when using this MACRO?
>
> Thanks!
>
> "Alireza Dabagh [MS]" <alid(a)online.microsoft.com> wrote in message
> news:u$%23vINFoIHA.1236(a)TK2MSFTNGP02.phx.gbl...
>> Peter, you should use NDIS APIs to move these data offsets
>> (NdisAdvance/RetreatNetBuffer(List)DataStart). Otherwise NB->MdlChain +
>> NB->DataOffset will not be consistent with NB->CurrentMdl and
>> NB->CurrentMdlOffset.
>>
>> NDIS assumes the first MDL in the NB and the NB->DataOffset fields are
>> always correct while the NB->CurrentMdl and NB->CurrentMdlOffset fields
>> may be uninitialized. As a result, NDIS in some API calls may
>> recalculates these fields based on the value of NB->MdlChain and
>> NB->DataOffset and in the process overrides your modification to
>> CurrentMdl and CurrentMdlOffset.
>>
>> What you are doing leads to data corruption and by the time you get the
>> NBL back, CurrentMdl and CurrentMdlOffset might not be what you set them
>> to.
>>
>> -ali
>>
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Peter" <x@y> wrote in message
>> news:%23MVg7bCoIHA.4848(a)TK2MSFTNGP05.phx.gbl...
>>> Hi!
>>>
>>> My understanding of how protocols/IM drivers parse indicated rx NBLs/NBs
>>> is by accessing the data starting at NET_BUFFER_CURRENT_MDL(NB) and
>>> offset by NET_BUFFER_CURRENT_MDL_OFFSET(NB).
>>>
>>> Our miniport driver will occasionally shift the offset within the
>>> NET_BUFFER_CURRENT_MDL(NB) and will set
>>> NET_BUFFER_CURRENT_MDL_OFFSET(NB) appropriately. Unfortunately, the NDIS
>>> 6.5 offloadchecksum test fails and reports data corruption because it is
>>> not taking the NET_BUFFER_CURRENT_MDL_OFFSET(NB) into consideration. I
>>> have verified this by looking at the MDL it reports as containing
>>> corrupted data. In all cases, the test is looking at data at
>>> MDL->MappedSystemVa without offsetting this by the
>>> NET_BUFFER_CURRENT_MDL_OFFSET.
>>>
>>> Note that this is the only test that fails. All other tests, such as
>>> offloadlso, works.
>>>
>>> Is this a known problem with the NDIS 6.2/NDIS.Net that comes with DTM
>>> 1.2?
>>>
>>> Thanks!
>>>
>>>
>>
>
>

 | 
Pages: 1
Prev: EWT and Logman.exe for dummies
Next: How to detect the mouse horizontal scroll?