Re: Direct Copying To Share Memory In NDIS ProtocolReceive


Anton Bassov wrote:
No matter how you look at it, apps still have to synchronize their access to
the shared buffer, which means that thet will inevitably have to call
WaitXXX() functions that involve user-to-kernel transition before they can
access the buffer. If you just make your driver pend IRP_MJ_READ, apparently,
asynch IO completion routine will have to re-submit the request, i.e. call
ReadFileEx() upon every invocation. Is ReadFileEx() much more expensive that
WaitXXX() functions? I don't think so - after all, when you make a call that
involves a transition to the kernel mode, the lion's share of time is spent
on parameter validation, rather than on processing the call itself.
Therefore, sharing a buffer does not seem to offer an advantage so
significant that it is worth all the pain of dealing with things that you
don't need
to think about when using "standard" IO.

Yes, to be clear, the applications must WaitForSingleObjects to get
access to the buffer.

Another concern is locking memory. If you use METHOD_BUFFERED, the system
will have to copy all data from the system buffer to the user one, and vice
versa. If you use METHOD_DIRECT, the system does not have to copy data.
However, again, the same question arises - is copying data is so expensive
operation? You save few machine cycles, but, as a result, have to lock memory
for the extended periods of time (i.e. while "prime" app is active). This is
not a big deal if shared section is just few pages in size, but if it is
reasonably large, locking memory for the extended periods of time may lead to
overall performance degradation - you get the pain
of dealing with all additional complexities.......and get performance
degradation, rather than improvement!!!!

Just curious...what would be unreasonable? How many pages? I am
locking 256 pages at present.

If I was in the OP's place, if would first try to do everything "stupid and
simple", and see how it all works - I wold start thinking about optimization
if and only if I am not happy with the performance. However, the OP starts
thinking about it in the very beginning of his project.

That is the way I work. I think about the end result, then spend much
time thinking about how I can get there without doing anything. I
mull, which is what I am doing now.

According to Knuth, " in 95% of cases optimization is mother of all evil". I
think that there is a good chance that the OP's case falls into these 95%

Actually, I believe Knuth said "Premature optimization is the root of
all evil." In this case, the optimization is not premature, any more
than considerations of optimization would be premature in the design
of a hash-based associative set. The whole reason for even considering
the design I had in mind was optimization. So in this case, my form
is driven by optimization. If the goal where simply to receive and
transmit packets, I would have just done that.

But you are right, I definitely should consider whether it is worth
deviating from something "normal", which is why I was trying to get an
indication of how much performance increase I could expect on packet
receive indications.

-Le Chaud Lapin-

.

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... >>determining whether a program has a buffer overflow. ... > you get around undecidability is almost always the same; ... > optimization is undecidable; nonetheless, a good optimizer will only apply ... So maybe there's a useful subset of C that can be accurately ...
    (sci.crypt)
  • Re: Is there a STL equivalent of sprintf
    ... number of conversions. ... Have you considered ostrstream or istrstream with a fixed size buffer? ... I've played around with various optimization before and I think I've tested fix buffers too. ... Since sprintf is used internally in stringstreams I don't see a performance advantage to prefer the stream library for string conversion of integers. ...
    (microsoft.public.vc.stl)
  • Re: [Lit.] Buffer overruns
    ... >overflows: Say you've got a function fand you want to see if it ... >determining whether a program has a buffer overflow. ... them -- but you don't have the undecidability problem any further. ... optimization is undecidable; nonetheless, a good optimizer will only apply ...
    (sci.crypt)
  • Re: Direct Copying To Share Memory In NDIS ProtocolReceive
    ... I am not sure that frequency of data transfers is that important ... The buffer size may be important if the buffer is so huge that you are not ... I believe Knuth said "Premature optimization is the root of ... Well all I can say is for small transfers like packet size data, ...
    (microsoft.public.development.device.drivers)