Receive Packets

OSR_Community_User · October 29, 2001, 9:38am

Hello Everyone …
I’m dealing with PIM driver, but I guess that NDIS is something uneversal
…
I think, I dont have enough understanding of this process …
I have 2 Receive Handlers :

PtReceivePacket()
PtReceive()

Now I want to do some actions on received Packet.
I create a thread for this purpose and when I receive Packet, I put it into
a queue and return handler. After that My thread wakes up and processes
packet …

To make sure that packet is mine while processing I do “return 1” from
this handler.
In My thread I get the packet from the queue, do
“NdisReturnPacket(&MyPacket, 1)”
and execute Original ReceivePacket() handler.
Okay, It seems to be workable (I can call ping www.yahoo.com and it will
work …)
but everything else works very slowly …
I wonder why ?
What value should I return to retain ownership of the packet ???

Best Regards
Foxgen

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thomas_F_Divine · October 29, 2001, 11:03am

----- Original Message -----
From: “foxgen”
To: “NT Developers Interest List”
Sent: Monday, October 29, 2001 9:22 AM
Subject: [ntdev] Receive Packets

> Hello Everyone …
> I’m dealing with PIM driver, but I guess that NDIS is something uneversal
> …
> I think, I dont have enough understanding of this process …
> I have 2 Receive Handlers :
> 1. PtReceivePacket()
> 2. PtReceive()
>
> Now I want to do some actions on received Packet.
> I create a thread for this purpose and when I receive Packet, I put it
into
> a queue and return handler. After that My thread wakes up and processes
> packet …
>
> 1. To make sure that packet is mine while processing I do “return 1” from
> this handler.
> In My thread I get the packet from the queue, do
> “NdisReturnPacket(&MyPacket, 1)”
> and execute Original ReceivePacket() handler.
> Okay, It seems to be workable (I can call ping www.yahoo.com and it will
> work …)
> but everything else works very slowly …
> I wonder why ?
>

When you call NdisReturnPacket you are effectively telling NDIS that it is
OK to dispose of the packet if no other protocol has claimed it. So, it
could very well be that your logic is really:

1.) Dispose of packet.
2.) Call OriginalReceivePacket with a packet that has been destroyed.

At the least, consider calling NdisReturnPacket after your call to
OriginalReceivePacket.

Going further, you should really consider examining the packet more closely
in PtReceivePacket. If you really want to do something with the packet
(modify it, etc.), make a complete clone of the packet (new NDIS_PACKET,
NDIS_BUFFER and packet data VM) and return zero (0) from PtReceivePacket.
Then queue your clone and later pass your coloned packet to
OriginalReceivePacket.

This method will help you later when you deal with PtReceive. PtReceive does
not necessarily indicate a packet to you at all; just HeaderBuffer and
LookAheadBuffer. One way to deal with this is to construct a packet in
PtReceive and queue it for later processing. If you do this, then your
“later processing” won’t care whether the packet came in through PtReceive
or PtReceivePacket.

> 2. What value should I return to retain ownership of the packet ???

One (1) is fine. Inderstand that in a PIM driver that when you call this
your are actually acting as a “proxy” for the higher-level protocol.

Good luck,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client/Filter
http: - http:

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:>

OSR_Community_User · October 30, 2001, 6:42am

if I call NdisReturnPacket after OriginalReceivePacket handler everything
remains
very slowly …

Ok! Now I’m trying to do the sceme, you proposed …

Make a clone packet. Set all attributes as they are in original packet
Queue MyPacket and “return 0”
Question : What will happen to original packet ? I guess it will be
dropped, isn’t it ?
Get MyPacket from queue. Pass it through OriginalReceivePacket.
Free(MyPacket). because I’ve allocated it before and should destroy it
myself …
But something tells me, it’s not right … Where should I free MyPacket
??
a. In ProtocolReceiveComplete routine
b. In my own callback where I pass it through OriginalReceivePacket
c. Somewhere else … then where ???

Is that right ??
Shouldn’t there be a place for MiniportReturnPacket ??
What about OriginalPacket reference ? I guess, if original packet is
dropped, I shouldn’t worry about it, right ??

Thank You in advance.
Foxgen.

When you call NdisReturnPacket you are effectively telling NDIS that it is
OK to dispose of the packet if no other protocol has claimed it. So, it
could very well be that your logic is really:

1.) Dispose of packet.
2.) Call OriginalReceivePacket with a packet that has been destroyed.

At the least, consider calling NdisReturnPacket after your call to
OriginalReceivePacket.

Going further, you should really consider examining the packet more
closely
in PtReceivePacket. If you really want to do something with the packet
(modify it, etc.), make a complete clone of the packet (new NDIS_PACKET,
NDIS_BUFFER and packet data VM) and return zero (0) from PtReceivePacket.
Then queue your clone and later pass your coloned packet to
OriginalReceivePacket.

This method will help you later when you deal with PtReceive. PtReceive
does
not necessarily indicate a packet to you at all; just HeaderBuffer and
LookAheadBuffer. One way to deal with this is to construct a packet in
PtReceive and queue it for later processing. If you do this, then your
“later processing” won’t care whether the packet came in through PtReceive
or PtReceivePacket.

> 2. What value should I return to retain ownership of the packet ???

One (1) is fine. Inderstand that in a PIM driver that when you call this
your are actually acting as a “proxy” for the higher-level protocol.

Good luck,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client/Filter
http: - http:
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yandex.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></http:>

Michal_Vodicka-1 · October 30, 2001, 3:37pm

Haven’t you said you’re using a thread for packet processing? It may cause
performance problems. Try to measure the time between packet receiving and
real processing. You can use some profiling tool if you have (NuMega
TrueTime should help there) or simply use RDTSC instruction.

Note I haven’t examined your desing thoroughly, maybe there is another
problem.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, October 30, 2001 12:39 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Receive Packets

if I call NdisReturnPacket after OriginalReceivePacket handler
everything
remains
very slowly …

Ok! Now I’m trying to do the sceme, you proposed …

Make a clone packet. Set all attributes as they are in original packet

Queue MyPacket and “return 0”
Question : What will happen to original packet ? I guess it will be
dropped, isn’t it ?

Get MyPacket from queue. Pass it through OriginalReceivePacket.

Free(MyPacket). because I’ve allocated it before and should destroy
it
myself …
But something tells me, it’s not right … Where should I free
MyPacket
??
a. In ProtocolReceiveComplete routine
b. In my own callback where I pass it through OriginalReceivePacket
c. Somewhere else … then where ???

Is that right ??
Shouldn’t there be a place for MiniportReturnPacket ??
What about OriginalPacket reference ? I guess, if original packet is
dropped, I shouldn’t worry about it, right ??

Thank You in advance.
Foxgen.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 31, 2001, 4:01am

hmm … Can you advise some other scheme for packet processing (crypt\decrypt
for instance) ?
I use worker thread to process packets … Is there any alternative for that
? Timer callbacks ? DPC ?

Haven’t you said you’re using a thread for packet processing? It may cause
performance problems. Try to measure the time between packet receiving and
real processing. You can use some profiling tool if you have (NuMega
TrueTime should help there) or simply use RDTSC instruction.

Note I haven’t examined your desing thoroughly, maybe there is another
problem.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Michal_Vodicka-1 · October 31, 2001, 4:46pm

Why not de/crypt immediately? There is no problem on send path and on
receive path it depends where you receive packet. You shouldn’t do it in
ProtocolReceive but in ProtocolReceiveComplete instead (copy packet in
ProotocolReceive, queue and process later in ProtocolReceiveComplete). I
believe there is no problem with decryption in ProtocolReceivePacket. Of
course, your encryption shouldn’t be too slow, the best if it is comparable
with network speed or faster.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, October 31, 2001 9:57 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Receive Packets

hmm … Can you advise some other scheme for packet processing
(crypt\decrypt
for instance) ?
I use worker thread to process packets … Is there any alternative for
that
? Timer callbacks ? DPC ?

> Haven’t you said you’re using a thread for packet processing? It may
cause
> performance problems. Try to measure the time between packet receiving
and
> real processing. You can use some profiling tool if you have (NuMega
> TrueTime should help there) or simply use RDTSC instruction.
>
> Note I haven’t examined your desing thoroughly, maybe there is another
> problem.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · November 1, 2001, 5:27am

Okay ! This is pretty fine, but I still dont have enough knowledge about
receiving packets process
:((
My question is :
I indicate packet UP…
When am I allowed to destroy packet after indicating it ??
Can I destroy it immediately or should I wait for something ?

( I have a separate thread for indicating packets. )

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Michal_Vodicka-1 · November 1, 2001, 2:11pm

Have you considered reading docs?

Well, if my memory serves and if I consider PIM driver which hooks original
protocol handlers (right?):

if you indicate packet using protocol’s Receive handler: immediately after
returning. Protocol isn’t allowed to access packet buffers after returning
from this function.
if you indicate whole packet using protocol’s ReceivePacket handler,
decision is based on return value. If it returns zero it means all
processing is done and you can destroy the packet. If it returns 1, it
retained packet ownership and you have to wait until NdisReturnPackets with
this packet descriptor is called. Don’t forget it can be called before
ReceivePacket handler returns. And for return values > 1 please read the
docs for ProtocolReceivePacket.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
Reply To: xxxxx@lists.osr.com
Sent: Thursday, November 01, 2001 11:16 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Receive Packets

Okay ! This is pretty fine, but I still dont have enough knowledge about
receiving packets process
:((
My question is :
I indicate packet UP…
When am I allowed to destroy packet after indicating it ??
Can I destroy it immediately or should I wait for something ?

( I have a separate thread for indicating packets. )

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · November 2, 2001, 3:40am

Oops ! It works Now ! :))
Many thanks to You !!!

But … Is it okay to get slower network operations because of such
filtering packets ?
I do not perform any operations yet, just get packets, forward them to my
thread, and
let them go their own way there … But these ooperations slow down
downloading files
from local net… (I’ve got 100 mBit local net)
Is this sutuation okay, or it’s possible to improve situation ?

Have you considered reading docs?

Well, if my memory serves and if I consider PIM driver which hooks
original
protocol handlers (right?):

if you indicate packet using protocol’s Receive handler: immediately
after
returning. Protocol isn’t allowed to access packet buffers after returning
from this function.

if you indicate whole packet using protocol’s ReceivePacket handler,
decision is based on return value. If it returns zero it means all
processing is done and you can destroy the packet. If it returns 1, it
retained packet ownership and you have to wait until NdisReturnPackets
with
this packet descriptor is called. Don’t forget it can be called before
ReceivePacket handler returns. And for return values > 1 please read the
docs for ProtocolReceivePacket.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

> ----------
> From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
> Reply To: xxxxx@lists.osr.com
> Sent: Thursday, November 01, 2001 11:16 AM
> To: xxxxx@lists.osr.com
> Subject: [ntdev] Re: Receive Packets
>
> Okay ! This is pretty fine, but I still dont have enough knowledge about
> receiving packets process
> :((
> My question is :
> I indicate packet UP…
> When am I allowed to destroy packet after indicating it ??
> Can I destroy it immediately or should I wait for something ?
>
> ( I have a separate thread for indicating packets. )
>
>
>
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

You are currently subscribed to ntdev as: xxxxx@yandex.ru
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Michal_Vodicka-1 · November 2, 2001, 6:27pm

> ----------

From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
Reply To: xxxxx@lists.osr.com
Sent: Friday, November 02, 2001 9:38 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Receive Packets

But … Is it okay to get slower network operations because of such
filtering packets ?
I do not perform any operations yet, just get packets, forward them to my
thread, and
let them go their own way there … But these ooperations slow down
downloading files
from local net… (I’ve got 100 mBit local net)
Is this sutuation okay, or it’s possible to improve situation ?

No, it isn’t OK. You shouldn’t notice a difference if you’re only forwarding
packets. As I already wrote, your thread is probably the root of problem.
Try to write a forwarding driver without it and compare. I wrote several
encryption drivers and the only factor which really influenced network speed
was encryption speed.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · November 5, 2001, 4:37am

Hi foxgen

I had a bad performance problem, as well, Have you tried altering the
default makefile, to increase performance?

i.e.

Modify makefile.def, change /Oxs to /Ox /Ob2. This had a major impact on FTP
and file transfers on the driver
samples.

Steve

-----Original Message-----
From: foxgen
To: NT Developers Interest List
Date: Friday, November 02, 2001 8:55 AM
Subject: [ntdev] Re: Receive Packets

>Oops ! It works Now ! :))
>Many thanks to You !!!
>
>But … Is it okay to get slower network operations because of such
>filtering packets ?
>I do not perform any operations yet, just get packets, forward them to my
>thread, and
>let them go their own way there … But these ooperations slow down
>downloading files
>from local net… (I’ve got 100 mBit local net)
>Is this sutuation okay, or it’s possible to improve situation ?
>
>
>> Have you considered reading docs?
>>
>> Well, if my memory serves and if I consider PIM driver which hooks
>original
>> protocol handlers (right?):
>> - if you indicate packet using protocol’s Receive handler: immediately
>after
>> returning. Protocol isn’t allowed to access packet buffers after
returning
>> from this function.
>> - if you indicate whole packet using protocol’s ReceivePacket handler,
>> decision is based on return value. If it returns zero it means all
>> processing is done and you can destroy the packet. If it returns 1, it
>> retained packet ownership and you have to wait until NdisReturnPackets
>with
>> this packet descriptor is called. Don’t forget it can be called before
>> ReceivePacket handler returns. And for return values > 1 please read the
>> docs for ProtocolReceivePacket.
>>
>> Best regards,
>>
>> Michal Vodicka
>> STMicroelectronics Design and Application s.r.o.
>> [michal.vodicka@st.com, http:://www.st.com]
>>
>> > ----------
>> > From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
>> > Reply To: xxxxx@lists.osr.com
>> > Sent: Thursday, November 01, 2001 11:16 AM
>> > To: xxxxx@lists.osr.com
>> > Subject: [ntdev] Re: Receive Packets
>> >
>> > Okay ! This is pretty fine, but I still dont have enough knowledge
about
>> > receiving packets process
>> > :((
>> > My question is :
>> > I indicate packet UP…
>> > When am I allowed to destroy packet after indicating it ??
>> > Can I destroy it immediately or should I wait for something ?
>> >
>> > ( I have a separate thread for indicating packets. )
>> >
>> >
>> >
>> >
>> > —
>> > You are currently subscribed to ntdev as: michal.vodicka@st.com
>> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>> >
>>
>> —
>> You are currently subscribed to ntdev as: xxxxx@yandex.ru
>> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>>
>
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@bemac.com
>To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · November 5, 2001, 8:15am

well, it doesnt help much …

I had a bad performance problem, as well, Have you tried altering the
default makefile, to increase performance?

i.e.

Modify makefile.def, change /Oxs to /Ox /Ob2. This had a major impact on
FTP
and file transfers on the driver
samples.

Steve

-----Original Message-----
From: foxgen
> To: NT Developers Interest List
> Date: Friday, November 02, 2001 8:55 AM
> Subject: [ntdev] Re: Receive Packets
>
>
> >Oops ! It works Now ! :))
> >Many thanks to You !!!
> >
> >But … Is it okay to get slower network operations because of such
> >filtering packets ?
> >I do not perform any operations yet, just get packets, forward them to my
> >thread, and
> >let them go their own way there … But these ooperations slow down
> >downloading files
> >from local net… (I’ve got 100 mBit local net)
> >Is this sutuation okay, or it’s possible to improve situation ?
> >
> >
> >> Have you considered reading docs?
> >>
> >> Well, if my memory serves and if I consider PIM driver which hooks
> >original
> >> protocol handlers (right?):
> >> - if you indicate packet using protocol’s Receive handler: immediately
> >after
> >> returning. Protocol isn’t allowed to access packet buffers after
> returning
> >> from this function.
> >> - if you indicate whole packet using protocol’s ReceivePacket handler,
> >> decision is based on return value. If it returns zero it means all
> >> processing is done and you can destroy the packet. If it returns 1, it
> >> retained packet ownership and you have to wait until NdisReturnPackets
> >with
> >> this packet descriptor is called. Don’t forget it can be called before
> >> ReceivePacket handler returns. And for return values > 1 please read
the
> >> docs for ProtocolReceivePacket.
> >>
> >> Best regards,
> >>
> >> Michal Vodicka
> >> STMicroelectronics Design and Application s.r.o.
> >> [michal.vodicka@st.com, http:://www.st.com]
> >>
> >> > ----------
> >> > From: xxxxx@yandex.ru[SMTP:xxxxx@yandex.ru]
> >> > Reply To: xxxxx@lists.osr.com
> >> > Sent: Thursday, November 01, 2001 11:16 AM
> >> > To: xxxxx@lists.osr.com
> >> > Subject: [ntdev] Re: Receive Packets
> >> >
> >> > Okay ! This is pretty fine, but I still dont have enough knowledge
> about
> >> > receiving packets process
> >> > :((
> >> > My question is :
> >> > I indicate packet UP…
> >> > When am I allowed to destroy packet after indicating it ??
> >> > Can I destroy it immediately or should I wait for something ?
> >> >
> >> > ( I have a separate thread for indicating packets. )
> >> >
> >> >
> >> >
> >> >
> >> > —
> >> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> >> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >> >
> >>
> >> —
> >> You are currently subscribed to ntdev as: xxxxx@yandex.ru
> >> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >>
> >
> >
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@bemac.com
> >To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yandex.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com