Too many ioctls

NTDEV
1

hi all
i have another query

i am implementing a processing engine which executes in kernel.
the processing engine while executing requires acess to some data structures
which are therefore maintained in the kernel.
Some part of these data structures are configured by requests recevied from
the user mode via ioctls.

Now the problem is that there are too many configuration parameters required
for processing engine inside the kernel to execute.
Now i want to know that if i issue too many ioctls requests to configure
some small things then will there be any issues. these too many
requests will just to get /set the data structures inside the kernel mode.
The other option is to maitain a shared memory between the kernel and the
user mode which can be accessed by both. i dont know if this possible and if
possible then how
much of an overhead will it be for the kernel thread to access this shared
memory. Also in this case there will have to be some lock mechanims because
both the kernel and user may simulataneolsy access these data structures for
writing and reading.

The issue is whicn approach to take
---- implement a functions as collection of a number of IOCTLS versus
---- implement a functions as a single IOCTL

Regards
Mayank

2

There is a somewhat limited number of ioctl values that you can assign,
something like 10 or 12 bits worth, I think. So you are limited to
something like 1000 separate ioctls. In your driver these all show up at
one entry point, so you have to decode the ioctl value with a switch
statement or the like.

I would probably not make an ioctl for every possible variable, especially
if the number of variables can change. It would probably be more practical
to make get_integer, get_string, set_integer, set_string type ioctls, and
then pass an enumerated value to these ioctls to identify the specific field
you want to manipulate.

If you are doing very very many of these per second all the time (and not
just a bunch to set things up and then a few from time to time) the overhead
might get to be a problem. In that case you could consider using shared
memory. This is fairly easy to set up, and obviously lets you manipulate
variables quickly. You would have to determine if you needed to lock every
access, or if you could do a group of accesses with a single lock. Fiddling
locks on and off also has overhead, although probably not as much as
processing an ioctl.

Loren

3

hi loren
i understand ur point.
but ur get-integer will get a copy of the integer allocated in kernel stack.
similarly if i want to have somthing like get_data(ABC_Type, Buffer)
where the memory for ABC_Type variable was allocated in the kernel, then is
it possible.

what i have in mind is the following:-

typedef struct abc_type {
struct x * a1;
struct y * a2;
void * dhsj
int type;
}ABC_type;

kernel mode code

ABC_Type *abc = (ABC_Type *) ExAllocatePool()
abc->a1 = (struct x *) ExAllocatePool()
abc->a1->a =132
abc->type =3232 ,etc

then
user mode code

void *inp_buffer;
ABC_Type *xyz
/* to read the data structure from the kernel */
DeviceIoControl(inp_buffer,READ_CODE)

/* to update the data structure read from the kernel */
xyz = (ABC_Type *) inp_buffer

xyz->a1->a=999
xyz->type=-1

/* to update the data structure in the kernel */
DeviceIoControl(inp_buffer,WRITE_CODE)

IS THIS POSSIBLE
please tell me

I think my questions may be obvious to all of you , but since i am a newbie
in this field, i am seeking ur help

Regards
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Saturday, May 17, 2003 8:04 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

There is a somewhat limited number of ioctl values that you can assign,
something like 10 or 12 bits worth, I think. So you are limited to
something like 1000 separate ioctls. In your driver these all show up at
one entry point, so you have to decode the ioctl value with a switch
statement or the like.

I would probably not make an ioctl for every possible variable, especially
if the number of variables can change. It would probably be more practical
to make get_integer, get_string, set_integer, set_string type ioctls, and
then pass an enumerated value to these ioctls to identify the specific field
you want to manipulate.

If you are doing very very many of these per second all the time (and not
just a bunch to set things up and then a few from time to time) the overhead
might get to be a problem. In that case you could consider using shared
memory. This is fairly easy to set up, and obviously lets you manipulate
variables quickly. You would have to determine if you needed to lock every
access, or if you could do a group of accesses with a single lock. Fiddling
locks on and off also has overhead, although probably not as much as
processing an ioctl.

Loren

You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Think of an ioctl as a memcpy. If you set up your control codes with
METHOD_BUFFERED the OS will do a lot of the memory handling for you.

NTSTATUS MyIoctlRoutine(…)
{
switch (control_code)
{
case update_struct:
ULONG thing_index = *(ULONG*)Irp->AssociatedIrp.SystemBuffer;
Thing* MyThing = thingtable[thing_index];
MyThing->a = *(USHORT*)Irp->AssociatedIrp.SystemBuffer[3];
// etc. Much cleaner to declare a structure that will be what the
user has
// in his buffer, of course.

Since the data is copied you don’t have the same addressing environment, so
you can’t pass pointers back and forth. If everything in the driver is
allocated from a single memory block, you can convert the pointers to
offsets from the front of the block to pass them back and forth.
Alternately and probably better, the user program only updates non-pointer
variables.

Since the user program can’t pass a pointer to the thing in driver space it
wants to update, it has to do it some other way. Again, this could be an
offset from the front of a single common allocation. Or the trick I showed
above, where you have an array of pointers to all of the things you have
allocated, and you talk about them by array index.

There are lots of other ways to do this sort of thing. Think of the
interface as RPC where you have to marshall the arguments to pass them
across the system interface.

Loren

5

hi loren

see inline

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Saturday, May 17, 2003 9:49 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

Think of an ioctl as a memcpy. If you set up your control codes with
METHOD_BUFFERED the OS will do a lot of the memory handling for you.

NTSTATUS MyIoctlRoutine(…)
{
switch (control_code)
{
case update_struct:
ULONG thing_index = *(ULONG*)Irp->AssociatedIrp.SystemBuffer;
Thing* MyThing = thingtable[thing_index];
MyThing->a = *(USHORT*)Irp->AssociatedIrp.SystemBuffer[3];
// etc. Much cleaner to declare a structure that will be what the
user has
// in his buffer, of course.

Since the data is copied you don’t have the same addressing environment, so
you can’t pass pointers back and forth. If everything in the driver is
allocated from a single memory block, you can convert the pointers to
offsets from the front of the block to pass them back and forth.
Alternately and probably better, the user program only updates non-pointer
variables.
[MAYANK] write! the user (user mode ) only updates non pointer variables
BUT how does the user mode get access to the “single memory block” that was
allocated in the kernel to update variables located at its offset locations

Since the user program can’t pass a pointer to the thing in driver space it
wants to update, it has to do it some other way. Again, this could be an
offset from the front of a single common allocation. Or the trick I showed
above, where you have an array of pointers to all of the things you have
allocated, and you talk about them by array index.

There are lots of other ways to do this sort of thing. Think of the
interface as RPC where you have to marshall the arguments to pass them
across the system interface.

Loren

You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> [MAYANK] write! the user (user mode ) only updates non pointer variables

BUT how does the user mode get access to the “single memory block” that
was
allocated in the kernel to update variables located at its offset
locations

You missed my point. My first statement:

Think of an ioctl as a memcpy.

When your user program does a READ or a WRITE, what happens? Data is
transferred from (or to) a buffer in user space from some place on a device,
right?

Well, “memory” can be a device.

So your ioctl to change or read variables “reads” from the kernel memory
buffer and copies into a user memory buffer. Your ioctl to set variables
copies from the user buffer to the kernel memory buffer.

So you don’t “get access to” the kernel memor buffer using that method. You
make a copy of the data in user space instead.

Loren

7

hi loren
thanks for having the patience to explain me things.
i got it. now is this method also possible if i want to read the value and
modify a struct of the following type

typedef struct grp {

struct prod_type *prod[10]
struct cons_type *cons[10]
struct svc_type *svces[10]

some more data types …
}Group

this will be allocated in the kernel. will i be able to pass a copy of this
buffer to user mode, get it modified there and then recopy it back to
kernel.

Thanks
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Loren Wilton
Sent: Sunday, May 18, 2003 1:56 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

[MAYANK] write! the user (user mode ) only updates non pointer variables
BUT how does the user mode get access to the “single memory block” that
was
allocated in the kernel to update variables located at its offset
locations

You missed my point. My first statement:

Think of an ioctl as a memcpy.

When your user program does a READ or a WRITE, what happens? Data is
transferred from (or to) a buffer in user space from some place on a device,
right?

Well, “memory” can be a device.

So your ioctl to change or read variables “reads” from the kernel memory
buffer and copies into a user memory buffer. Your ioctl to set variables
copies from the user buffer to the kernel memory buffer.

So you don’t “get access to” the kernel memor buffer using that method. You
make a copy of the data in user space instead.

Loren

You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

The kind of questions are you are posing here makes me wonder why you are
doing implementing this processing engine in kernel mode at all. Why can’t
you do it in user mode ? You have full access to RPCs and other good stuff.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi all
> i have another query
>
> i am implementing a processing engine which executes in kernel.
> the processing engine while executing requires acess to some data
structures
> which are therefore maintained in the kernel.
> Some part of these data structures are configured by requests recevied
from
> the user mode via ioctls.
>
> Now the problem is that there are too many configuration parameters
required
> for processing engine inside the kernel to execute.
> Now i want to know that if i issue too many ioctls requests to configure
> some small things then will there be any issues. these too many
> requests will just to get /set the data structures inside the kernel mode.
> The other option is to maitain a shared memory between the kernel and the
> user mode which can be accessed by both. i dont know if this possible and
if
> possible then how
> much of an overhead will it be for the kernel thread to access this shared
> memory. Also in this case there will have to be some lock mechanims
because
> both the kernel and user may simulataneolsy access these data structures
for
> writing and reading.
>
> The issue is whicn approach to take
> ---- implement a functions as collection of a number of IOCTLS versus
> ---- implement a functions as a single IOCTL
>
> Regards
> Mayank
>
>
>
>
>
>
>

9

hi nar
i didnt get u by the ‘kind of questions’. The processing engine has certain
real time requirements which i feel cannot be met
in the user mode. the processing requirements of the processing engine keep
on increasing and decreasing dynamically based on the number of connections
that it has to handle. I dont think that these type of dynamic real time
requirements can be met in user mode specially in the case of intensive
processing algorithms that occur on each connection that is handled in the
kernel mode. You can think of it as real time streaming kind of thing.

I hope i am clear

Regards
Maynk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
Sent: Monday, May 19, 2003 9:50 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

The kind of questions are you are posing here makes me wonder why you are
doing implementing this processing engine in kernel mode at all. Why can’t
you do it in user mode ? You have full access to RPCs and other good stuff.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi all
> i have another query
>
> i am implementing a processing engine which executes in kernel.
> the processing engine while executing requires acess to some data
structures
> which are therefore maintained in the kernel.
> Some part of these data structures are configured by requests recevied
from
> the user mode via ioctls.
>
> Now the problem is that there are too many configuration parameters
required
> for processing engine inside the kernel to execute.
> Now i want to know that if i issue too many ioctls requests to configure
> some small things then will there be any issues. these too many
> requests will just to get /set the data structures inside the kernel mode.
> The other option is to maitain a shared memory between the kernel and the
> user mode which can be accessed by both. i dont know if this possible and
if
> possible then how
> much of an overhead will it be for the kernel thread to access this shared
> memory. Also in this case there will have to be some lock mechanims
because
> both the kernel and user may simulataneolsy access these data structures
for
> writing and reading.
>
> The issue is whicn approach to take
> ---- implement a functions as collection of a number of IOCTLS versus
> ---- implement a functions as a single IOCTL
>
> Regards
> Mayank
>
>
>
>
>
>
>

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.

Neither can they be met in Kernel mode, unless your timing restrictions are
sufficiently relaxed that UM would suffice. NT is not a real-time OS.
Other kernel components can starve you and put you outside your timing
specs. And there is nothing you can do about that. If you really need real
time, use an RTOS or a real-time extension to NT.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

11

> i didnt get u by the ‘kind of questions’. The processing engine has
certain

real time requirements which i feel cannot be met
in the user mode. the processing requirements of the processing engine
keep
on increasing and decreasing dynamically based on the number of
connections
that it has to handle. I dont think that these type of dynamic real time
requirements can be met in user mode specially in the case of intensive
processing algorithms that occur on each connection that is handled in the
kernel mode. You can think of it as real time streaming kind of thing.

It is always good in these cases to actually implement it in user space and
SEE if the requirements can be met, before going to any work at all to move
it to kernel space. I have stuff in user mode that will normally send out
hardware events with around 250us response accuracy, and almost never has a
jitter of more than 2-3ms.

I find it highly questionable that you will inherently get much higher
accuracy by implementing in kernel space. Indeed, you will quite possibly
end up worse off, unless you go to A LOT of work. Work you wouldn’t have to
do in user space.

Loren

12

hi phil
are there real time extensions to NT also available. can
u forward me some links.
regards
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Phil Barila
Sent: Tuesday, May 20, 2003 1:29 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.

Neither can they be met in Kernel mode, unless your timing restrictions are
sufficiently relaxed that UM would suffice. NT is not a real-time OS.
Other kernel components can starve you and put you outside your timing
specs. And there is nothing you can do about that. If you really need real
time, use an RTOS or a real-time extension to NT.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

When I said “Kind of questions” I meant that most of questions seem to be
software and non-device related. The windows scheduler does not treat the
kernel mode threads any different than user mode threads. So you really
don’t gain anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can preempt a
kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
right answer either. You cannot do a lot of things at this level). Writing
this kind of code in kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.
>
> I hope i am clear
>
> Regards
> Maynk
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> Sent: Monday, May 19, 2003 9:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> The kind of questions are you are posing here makes me wonder why you are
> doing implementing this processing engine in kernel mode at all. Why can’t
> you do it in user mode ? You have full access to RPCs and other good
stuff.
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi all
> > i have another query
> >
> > i am implementing a processing engine which executes in kernel.
> > the processing engine while executing requires acess to some data
> structures
> > which are therefore maintained in the kernel.
> > Some part of these data structures are configured by requests recevied
> from
> > the user mode via ioctls.
> >
> > Now the problem is that there are too many configuration parameters
> required
> > for processing engine inside the kernel to execute.
> > Now i want to know that if i issue too many ioctls requests to configure
> > some small things then will there be any issues. these too many
> > requests will just to get /set the data structures inside the kernel
mode.
> > The other option is to maitain a shared memory between the kernel and
the
> > user mode which can be accessed by both. i dont know if this possible
and
> if
> > possible then how
> > much of an overhead will it be for the kernel thread to access this
shared
> > memory. Also in this case there will have to be some lock mechanims
> because
> > both the kernel and user may simulataneolsy access these data structures
> for
> > writing and reading.
> >
> > The issue is whicn approach to take
> > ---- implement a functions as collection of a number of IOCTLS versus
> > ---- implement a functions as a single IOCTL
> >
> > Regards
> > Mayank
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

14

I have worked with GigaStudio, a software sampler for musicians. To achieve
low latencies, part of the application is made out of kernel components and
to use the software on a specific audio card, you need to have a kernel
driver that implements their interface.

I never really was convinced it is so much better to use the kernel. Other
driver interfaces (namely, ASIO) are all user-mode and have pretty much the
same low latencies. And when I look at the GigaStudio sample driver, which
is crippled to the bone, I don’t get the impression these guys really know
what they’re doing :slight_smile: But maybe they have a good reason, the thing is I
don’t know yet what it is!

But anyways, I agree: user-mode might be under-estimated and a higher
priority thread is worth considering!

Mat

-----Original Message-----
From: Nar Ganapathy [MS] [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, May 20, 2003 9:49 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

When I said “Kind of questions” I meant that most of questions seem to be
software and non-device related. The windows scheduler does not treat the
kernel mode threads any different than user mode threads. So you really
don’t gain anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can preempt a
kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
right answer either. You cannot do a lot of things at this level). Writing
this kind of code in kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.
>
> I hope i am clear
>
> Regards
> Maynk
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> Sent: Monday, May 19, 2003 9:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> The kind of questions are you are posing here makes me wonder why you are
> doing implementing this processing engine in kernel mode at all. Why can’t
> you do it in user mode ? You have full access to RPCs and other good
stuff.
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi all
> > i have another query
> >
> > i am implementing a processing engine which executes in kernel.
> > the processing engine while executing requires acess to some data
> structures
> > which are therefore maintained in the kernel.
> > Some part of these data structures are configured by requests recevied
> from
> > the user mode via ioctls.
> >
> > Now the problem is that there are too many configuration parameters
> required
> > for processing engine inside the kernel to execute.
> > Now i want to know that if i issue too many ioctls requests to configure
> > some small things then will there be any issues. these too many
> > requests will just to get /set the data structures inside the kernel
mode.
> > The other option is to maitain a shared memory between the kernel and
the
> > user mode which can be accessed by both. i dont know if this possible
and
> if
> > possible then how
> > much of an overhead will it be for the kernel thread to access this
shared
> > memory. Also in this case there will have to be some lock mechanims
> because
> > both the kernel and user may simulataneolsy access these data structures
> for
> > writing and reading.
> >
> > The issue is whicn approach to take
> > ---- implement a functions as collection of a number of IOCTLS versus
> > ---- implement a functions as a single IOCTL
> >
> > Regards
> > Mayank
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

—
You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

15

Hi nar
i absolutely got your point. the notion i had in mind was that a kernel mode
thread would anyways
get higher priority then a user mode thread. But if you r very sure of what
u are saying then i will
definitley have to rethink my design. Can u suggest some real time
extensions to NT as well which you
are aware of and which Mircosoft supports as well.
Then what should be the approach. anyways i have to receive packets from the
network (so protocol driver is still required)
then do some processing on it.You can think of the picture as that at a time
i have to support many real time streaming audio connections from the
network to the windows 2000 server. So are there any advantages to
implementing this processing engine and connection mgmt in the kernel rather
then in the user mode.
if we implement this whole thing in the user mode then what should be the
most optimum way to receive network packets from the protocol driver into
the user mode so as to be able to support multiple real time connections
simultaneously.

Thanks
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy [MS]
Sent: Tuesday, May 20, 2003 7:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

When I said “Kind of questions” I meant that most of questions seem to be
software and non-device related. The windows scheduler does not treat the
kernel mode threads any different than user mode threads. So you really
don’t gain anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can preempt a
kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
right answer either. You cannot do a lot of things at this level). Writing
this kind of code in kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.
>
> I hope i am clear
>
> Regards
> Maynk
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> Sent: Monday, May 19, 2003 9:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> The kind of questions are you are posing here makes me wonder why you are
> doing implementing this processing engine in kernel mode at all. Why can’t
> you do it in user mode ? You have full access to RPCs and other good
stuff.
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi all
> > i have another query
> >
> > i am implementing a processing engine which executes in kernel.
> > the processing engine while executing requires acess to some data
> structures
> > which are therefore maintained in the kernel.
> > Some part of these data structures are configured by requests recevied
> from
> > the user mode via ioctls.
> >
> > Now the problem is that there are too many configuration parameters
> required
> > for processing engine inside the kernel to execute.
> > Now i want to know that if i issue too many ioctls requests to configure
> > some small things then will there be any issues. these too many
> > requests will just to get /set the data structures inside the kernel
mode.
> > The other option is to maitain a shared memory between the kernel and
the
> > user mode which can be accessed by both. i dont know if this possible
and
> if
> > possible then how
> > much of an overhead will it be for the kernel thread to access this
shared
> > memory. Also in this case there will have to be some lock mechanims
> because
> > both the kernel and user may simulataneolsy access these data structures
> for
> > writing and reading.
> >
> > The issue is whicn approach to take
> > ---- implement a functions as collection of a number of IOCTLS versus
> > ---- implement a functions as a single IOCTL
> >
> > Regards
> > Mayank
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

Try venturecom’s RT extensions to NT:
http://www.vci.com/products/windows_embedded/rtx.asp

-----Original Message-----
From: Mayank Kumar [mailto:xxxxx@intersolutions.stpn.soft.net]
Sent: Tuesday, May 20, 2003 11:26 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

Hi nar
i absolutely got your point. the notion i had in mind was
that a kernel mode thread would anyways get higher priority
then a user mode thread. But if you r very sure of what u are
saying then i will definitley have to rethink my design. Can
u suggest some real time extensions to NT as well which you
are aware of and which Mircosoft supports as well. Then what
should be the approach. anyways i have to receive packets
from the network (so protocol driver is still required) then
do some processing on it.You can think of the picture as that
at a time i have to support many real time streaming audio
connections from the network to the windows 2000 server. So
are there any advantages to implementing this processing
engine and connection mgmt in the kernel rather then in the
user mode. if we implement this whole thing in the user mode
then what should be the most optimum way to receive network
packets from the protocol driver into the user mode so as to
be able to support multiple real time connections simultaneously.

Thanks
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar
Ganapathy [MS]
Sent: Tuesday, May 20, 2003 7:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

When I said “Kind of questions” I meant that most of
questions seem to be software and non-device related. The
windows scheduler does not treat the kernel mode threads any
different than user mode threads. So you really don’t gain
anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can
preempt a kernel thread. (Running at DISPATCH_LEVEL to avoid
pre-emption is not the right answer either. You cannot do a
lot of things at this level). Writing this kind of code in
kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and
confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and
confers no rights.

“Mayank Kumar”
> wrote in message news:xxxxx@ntdev…
> >
> > hi nar
> > i didnt get u by the ‘kind of questions’. The processing engine has
> certain
> > real time requirements which i feel cannot be met
> > in the user mode. the processing requirements of the
> processing engine
> keep
> > on increasing and decreasing dynamically based on the number of
> connections
> > that it has to handle. I dont think that these type of dynamic real
> > time requirements can be met in user mode specially in the case of
> > intensive processing algorithms that occur on each
> connection that is
> > handled in the kernel mode. You can think of it as real
> time streaming
> > kind of thing.
> >
> > I hope i am clear
> >
> > Regards
> > Maynk
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Nar
> > Ganapathy[MS]
> > Sent: Monday, May 19, 2003 9:50 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Too many ioctls
> >
> >
> > The kind of questions are you are posing here makes me
> wonder why you
> > are doing implementing this processing engine in kernel
> mode at all.
> > Why can’t you do it in user mode ? You have full access to RPCs and
> > other good
> stuff.
> >
> > –
> > Nar Ganapathy
> > Windows Core OS group
> > This posting is provided “AS IS” with no warranties, and confers no
> rights.
> >
> > “Mayank Kumar” wrote in
> message
> > news:xxxxx@ntdev…
> > >
> > > hi all
> > > i have another query
> > >
> > > i am implementing a processing engine which executes in
> kernel. the
> > > processing engine while executing requires acess to some data
> > structures
> > > which are therefore maintained in the kernel.
> > > Some part of these data structures are configured by requests
> > > recevied
> > from
> > > the user mode via ioctls.
> > >
> > > Now the problem is that there are too many configuration
> parameters
> > required
> > > for processing engine inside the kernel to execute.
> > > Now i want to know that if i issue too many ioctls requests to
> > > configure some small things then will there be any
> issues. these too
> > > many requests will just to get /set the data structures
> inside the
> > > kernel
> mode.
> > > The other option is to maitain a shared memory between the kernel
> > > and
> the
> > > user mode which can be accessed by both. i dont know if this
> > > possible
> and
> > if
> > > possible then how
> > > much of an overhead will it be for the kernel thread to
> access this
> shared
> > > memory. Also in this case there will have to be some lock
> mechanims
> > because
> > > both the kernel and user may simulataneolsy access these data
> > > structures
> > for
> > > writing and reading.
> > >
> > > The issue is whicn approach to take
> > > ---- implement a functions as collection of a number of IOCTLS
> > > versus
> > > ---- implement a functions as a single IOCTL
> > >
> > > Regards
> > > Mayank
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@intersolutions.stpn.soft.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

17

Hi nar
so u mean to say that a kernel level thread running at PASSIVEL_IRQL is in
no way more frequently scheduled than
a user level thread running at higher priority. If i have certain audio
algorithms (with high mips requirements) which i need to apply on packets
received from the network, then will i not receive any advantage by
implementing the driver in kernel mode. At least the only advantage i can
see is that i will not have to pass/copy the buffers from the kernel mode
to user mode. So this much advantage can be a big one too. What do u say ??
Does Windows 2000 provide some thing called a zero copy packet transfers
like 2.4 kernel of linux provides.

Thanks
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy [MS]
Sent: Tuesday, May 20, 2003 7:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

When I said “Kind of questions” I meant that most of questions seem to be
software and non-device related. The windows scheduler does not treat the
kernel mode threads any different than user mode threads. So you really
don’t gain anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can preempt a
kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
right answer either. You cannot do a lot of things at this level). Writing
this kind of code in kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.
>
> I hope i am clear
>
> Regards
> Maynk
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> Sent: Monday, May 19, 2003 9:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> The kind of questions are you are posing here makes me wonder why you are
> doing implementing this processing engine in kernel mode at all. Why can’t
> you do it in user mode ? You have full access to RPCs and other good
stuff.
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi all
> > i have another query
> >
> > i am implementing a processing engine which executes in kernel.
> > the processing engine while executing requires acess to some data
> structures
> > which are therefore maintained in the kernel.
> > Some part of these data structures are configured by requests recevied
> from
> > the user mode via ioctls.
> >
> > Now the problem is that there are too many configuration parameters
> required
> > for processing engine inside the kernel to execute.
> > Now i want to know that if i issue too many ioctls requests to configure
> > some small things then will there be any issues. these too many
> > requests will just to get /set the data structures inside the kernel
mode.
> > The other option is to maitain a shared memory between the kernel and
the
> > user mode which can be accessed by both. i dont know if this possible
and
> if
> > possible then how
> > much of an overhead will it be for the kernel thread to access this
shared
> > memory. Also in this case there will have to be some lock mechanims
> because
> > both the kernel and user may simulataneolsy access these data structures
> for
> > writing and reading.
> >
> > The issue is whicn approach to take
> > ---- implement a functions as collection of a number of IOCTLS versus
> > ---- implement a functions as a single IOCTL
> >
> > Regards
> > Mayank
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

18

You need to be aware that a kernel thread also has a priority level, just
like user-mode threads. IRQL is a different thing: you can NOT compare a
kernel thread at PASSIVE and a user thread at HIGH priority.

Basically, there is no difference in the scheduling of a kernel thread at
NORMAL priority and a user thread at NORMAL priority, unless you increase
the IRQL in the kernel thread.

Mat

-----Original Message-----
From: Mayank Kumar [mailto:xxxxx@intersolutions.stpn.soft.net]
Sent: Tuesday, May 20, 2003 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

Hi nar
so u mean to say that a kernel level thread running at PASSIVEL_IRQL is in
no way more frequently scheduled than
a user level thread running at higher priority. If i have certain audio
algorithms (with high mips requirements) which i need to apply on packets
received from the network, then will i not receive any advantage by
implementing the driver in kernel mode. At least the only advantage i can
see is that i will not have to pass/copy the buffers from the kernel mode
to user mode. So this much advantage can be a big one too. What do u say ??
Does Windows 2000 provide some thing called a zero copy packet transfers
like 2.4 kernel of linux provides.

Thanks
Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy [MS]
Sent: Tuesday, May 20, 2003 7:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

When I said “Kind of questions” I meant that most of questions seem to be
software and non-device related. The windows scheduler does not treat the
kernel mode threads any different than user mode threads. So you really
don’t gain anything by writing a kernel mode driver (apart from the
increased complexity). A higher priority user mode thread can preempt a
kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
right answer either. You cannot do a lot of things at this level). Writing
this kind of code in kernel is absolutely the wrong idea. I think you
underestimate the complexity writing kernel mode code.

–

Nar Ganapathy

Windows Core OS group

This posting is provided “AS IS” with no warranties, and confers no rights.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> hi nar
> i didnt get u by the ‘kind of questions’. The processing engine has
certain
> real time requirements which i feel cannot be met
> in the user mode. the processing requirements of the processing engine
keep
> on increasing and decreasing dynamically based on the number of
connections
> that it has to handle. I dont think that these type of dynamic real time
> requirements can be met in user mode specially in the case of intensive
> processing algorithms that occur on each connection that is handled in the
> kernel mode. You can think of it as real time streaming kind of thing.
>
> I hope i am clear
>
> Regards
> Maynk
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> Sent: Monday, May 19, 2003 9:50 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> The kind of questions are you are posing here makes me wonder why you are
> doing implementing this processing engine in kernel mode at all. Why can’t
> you do it in user mode ? You have full access to RPCs and other good
stuff.
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi all
> > i have another query
> >
> > i am implementing a processing engine which executes in kernel.
> > the processing engine while executing requires acess to some data
> structures
> > which are therefore maintained in the kernel.
> > Some part of these data structures are configured by requests recevied
> from
> > the user mode via ioctls.
> >
> > Now the problem is that there are too many configuration parameters
> required
> > for processing engine inside the kernel to execute.
> > Now i want to know that if i issue too many ioctls requests to configure
> > some small things then will there be any issues. these too many
> > requests will just to get /set the data structures inside the kernel
mode.
> > The other option is to maitain a shared memory between the kernel and
the
> > user mode which can be accessed by both. i dont know if this possible
and
> if
> > possible then how
> > much of an overhead will it be for the kernel thread to access this
shared
> > memory. Also in this case there will have to be some lock mechanims
> because
> > both the kernel and user may simulataneolsy access these data structures
> for
> > writing and reading.
> >
> > The issue is whicn approach to take
> > ---- implement a functions as collection of a number of IOCTLS versus
> > ---- implement a functions as a single IOCTL
> >
> > Regards
> > Mayank
> >
> >
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

A thread in kernel mode is no different than a thread in user mode from a
scheduling point of view.

I agree that sharing memory buffers is tempting . You could use a
METHOD_DIRECT IOCTL or use DO_DIRECT_IO device object to get a locked read
buffer from user mode and post it to hardware. This avoids a copy. In my
opinion, the other benefits of user mode far outweighs this. If you also
look at this from other angles besides performance (for example deployment)
you will see that user mode is better. Think about how hard it is to do an
online upgrade of your driver to fix a bug in your engine.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> Hi nar
> so u mean to say that a kernel level thread running at PASSIVEL_IRQL is in
> no way more frequently scheduled than
> a user level thread running at higher priority. If i have certain audio
> algorithms (with high mips requirements) which i need to apply on packets
> received from the network, then will i not receive any advantage by
> implementing the driver in kernel mode. At least the only advantage i can
> see is that i will not have to pass/copy the buffers from the kernel mode
> to user mode. So this much advantage can be a big one too. What do u say
??
> Does Windows 2000 provide some thing called a zero copy packet transfers
> like 2.4 kernel of linux provides.
>
> Thanks
> Mayank
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy [MS]
> Sent: Tuesday, May 20, 2003 7:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> When I said “Kind of questions” I meant that most of questions seem to be
> software and non-device related. The windows scheduler does not treat the
> kernel mode threads any different than user mode threads. So you really
> don’t gain anything by writing a kernel mode driver (apart from the
> increased complexity). A higher priority user mode thread can preempt a
> kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
> right answer either. You cannot do a lot of things at this level). Writing
> this kind of code in kernel is absolutely the wrong idea. I think you
> underestimate the complexity writing kernel mode code.
>
>
>
> –
>
> Nar Ganapathy
>
> Windows Core OS group
>
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi nar
> > i didnt get u by the ‘kind of questions’. The processing engine has
> certain
> > real time requirements which i feel cannot be met
> > in the user mode. the processing requirements of the processing engine
> keep
> > on increasing and decreasing dynamically based on the number of
> connections
> > that it has to handle. I dont think that these type of dynamic real time
> > requirements can be met in user mode specially in the case of intensive
> > processing algorithms that occur on each connection that is handled in
the
> > kernel mode. You can think of it as real time streaming kind of thing.
> >
> > I hope i am clear
> >
> > Regards
> > Maynk
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> > Sent: Monday, May 19, 2003 9:50 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Too many ioctls
> >
> >
> > The kind of questions are you are posing here makes me wonder why you
are
> > doing implementing this processing engine in kernel mode at all. Why
can’t
> > you do it in user mode ? You have full access to RPCs and other good
> stuff.
> >
> > –
> > Nar Ganapathy
> > Windows Core OS group
> > This posting is provided “AS IS” with no warranties, and confers no
> rights.
> >
> > “Mayank Kumar” wrote in
> message
> > news:xxxxx@ntdev…
> > >
> > > hi all
> > > i have another query
> > >
> > > i am implementing a processing engine which executes in kernel.
> > > the processing engine while executing requires acess to some data
> > structures
> > > which are therefore maintained in the kernel.
> > > Some part of these data structures are configured by requests recevied
> > from
> > > the user mode via ioctls.
> > >
> > > Now the problem is that there are too many configuration parameters
> > required
> > > for processing engine inside the kernel to execute.
> > > Now i want to know that if i issue too many ioctls requests to
configure
> > > some small things then will there be any issues. these too many
> > > requests will just to get /set the data structures inside the kernel
> mode.
> > > The other option is to maitain a shared memory between the kernel and
> the
> > > user mode which can be accessed by both. i dont know if this possible
> and
> > if
> > > possible then how
> > > much of an overhead will it be for the kernel thread to access this
> shared
> > > memory. Also in this case there will have to be some lock mechanims
> > because
> > > both the kernel and user may simulataneolsy access these data
structures
> > for
> > > writing and reading.
> > >
> > > The issue is whicn approach to take
> > > ---- implement a functions as collection of a number of IOCTLS versus
> > > ---- implement a functions as a single IOCTL
> > >
> > > Regards
> > > Mayank
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@intersolutions.stpn.soft.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

20

hi nar
We are more concerned with the performance advantage rather then the
deployment advantage as far
as i know. But we will have more data once the first version is ready and we
are able to see some
performance figures.
Initially the approach i am taking is that the sofwtare will be written in
a way to be portable
between the user mode and kernel mode. it will be first tested in user mode
and then in kernel mode
to see if there are any difference in the performance numbers. I think it
should not be very difficult
enough to implement this approach.
Later on if we are very sure that no advantages are gained in terms of
performance inside the
kernel then we will have to have a method of efficiently tranferring packets
from the kernel to user mode
at the rate of approximately 1024 kbytes per second. If that is possible
then we will be able to
work in user mode also. i think a shared memory approach will save a lot of
effort but what i afraid
of is that a shared memory approach requires a lot of locks and other
synchronization mgmt which
will hit performance again.

What do u think about it ?

Mayank

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
Sent: Wednesday, May 21, 2003 3:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Too many ioctls

A thread in kernel mode is no different than a thread in user mode from a
scheduling point of view.

I agree that sharing memory buffers is tempting . You could use a
METHOD_DIRECT IOCTL or use DO_DIRECT_IO device object to get a locked read
buffer from user mode and post it to hardware. This avoids a copy. In my
opinion, the other benefits of user mode far outweighs this. If you also
look at this from other angles besides performance (for example deployment)
you will see that user mode is better. Think about how hard it is to do an
online upgrade of your driver to fix a bug in your engine.

–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.

“Mayank Kumar” wrote in message
news:xxxxx@ntdev…
>
> Hi nar
> so u mean to say that a kernel level thread running at PASSIVEL_IRQL is in
> no way more frequently scheduled than
> a user level thread running at higher priority. If i have certain audio
> algorithms (with high mips requirements) which i need to apply on packets
> received from the network, then will i not receive any advantage by
> implementing the driver in kernel mode. At least the only advantage i can
> see is that i will not have to pass/copy the buffers from the kernel mode
> to user mode. So this much advantage can be a big one too. What do u say
??
> Does Windows 2000 provide some thing called a zero copy packet transfers
> like 2.4 kernel of linux provides.
>
> Thanks
> Mayank
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy [MS]
> Sent: Tuesday, May 20, 2003 7:19 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Too many ioctls
>
>
> When I said “Kind of questions” I meant that most of questions seem to be
> software and non-device related. The windows scheduler does not treat the
> kernel mode threads any different than user mode threads. So you really
> don’t gain anything by writing a kernel mode driver (apart from the
> increased complexity). A higher priority user mode thread can preempt a
> kernel thread. (Running at DISPATCH_LEVEL to avoid pre-emption is not the
> right answer either. You cannot do a lot of things at this level). Writing
> this kind of code in kernel is absolutely the wrong idea. I think you
> underestimate the complexity writing kernel mode code.
>
>
>
> –
>
> Nar Ganapathy
>
> Windows Core OS group
>
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties, and confers no
rights.
>
> “Mayank Kumar” wrote in
message
> news:xxxxx@ntdev…
> >
> > hi nar
> > i didnt get u by the ‘kind of questions’. The processing engine has
> certain
> > real time requirements which i feel cannot be met
> > in the user mode. the processing requirements of the processing engine
> keep
> > on increasing and decreasing dynamically based on the number of
> connections
> > that it has to handle. I dont think that these type of dynamic real time
> > requirements can be met in user mode specially in the case of intensive
> > processing algorithms that occur on each connection that is handled in
the
> > kernel mode. You can think of it as real time streaming kind of thing.
> >
> > I hope i am clear
> >
> > Regards
> > Maynk
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Nar Ganapathy[MS]
> > Sent: Monday, May 19, 2003 9:50 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Too many ioctls
> >
> >
> > The kind of questions are you are posing here makes me wonder why you
are
> > doing implementing this processing engine in kernel mode at all. Why
can’t
> > you do it in user mode ? You have full access to RPCs and other good
> stuff.
> >
> > –
> > Nar Ganapathy
> > Windows Core OS group
> > This posting is provided “AS IS” with no warranties, and confers no
> rights.
> >
> > “Mayank Kumar” wrote in
> message
> > news:xxxxx@ntdev…
> > >
> > > hi all
> > > i have another query
> > >
> > > i am implementing a processing engine which executes in kernel.
> > > the processing engine while executing requires acess to some data
> > structures
> > > which are therefore maintained in the kernel.
> > > Some part of these data structures are configured by requests recevied
> > from
> > > the user mode via ioctls.
> > >
> > > Now the problem is that there are too many configuration parameters
> > required
> > > for processing engine inside the kernel to execute.
> > > Now i want to know that if i issue too many ioctls requests to
configure
> > > some small things then will there be any issues. these too many
> > > requests will just to get /set the data structures inside the kernel
> mode.
> > > The other option is to maitain a shared memory between the kernel and
> the
> > > user mode which can be accessed by both. i dont know if this possible
> and
> > if
> > > possible then how
> > > much of an overhead will it be for the kernel thread to access this
> shared
> > > memory. Also in this case there will have to be some lock mechanims
> > because
> > > both the kernel and user may simulataneolsy access these data
structures
> > for
> > > writing and reading.
> > >
> > > The issue is whicn approach to take
> > > ---- implement a functions as collection of a number of IOCTLS versus
> > > ---- implement a functions as a single IOCTL
> > >
> > > Regards
> > > Mayank
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@intersolutions.stpn.soft.net
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@intersolutions.stpn.soft.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>

—
You are currently subscribed to ntdev as:
xxxxx@intersolutions.stpn.soft.net
To unsubscribe send a blank email to xxxxx@lists.osr.com