Multiple NICs

NTDEV
1

This post expands on the adapter context issue discussed in the thread
“Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
Over the past few days I’ve been going through my driver and cleaned it up
tremendously based on the excellent advice I’ve received in this newsgroup.

Furthermore, I added support for multiple adapters by using a global,
spinlock-protected linked list containing the adapter context areas.

As stated earlier, my driver acts as a virtual network adapter which can
receive packets from a user-mode application and indicate them up to NDIS.
In the netvmini sample, Eliyas only registers a single, global device object
(not sure why, really) which is used by all adapter instances.
Now, if I send a packet down to the driver and multiple adapters are
running, which adapter should receive the IRP request? Earlier on, when I
was assuming only a single adapter would be installed, I would just insert
the IRP request in that adapter’s IRP safe-cancel queue.
I imagine one could register a device object for each adapter, but is this
the correct and desired approach?

Continuing on…
Imagine the above problem is solved; how do I gain access to the desired
adapter from the dispatch routine? Only the device object is passed as an
argument… This question is, of course, dependent on the solution above, and
such may be rendered superfluous.

Also, I’d like to take the opportunity to say a big thank you to the entire
community here. The excellent help is greatly appreciated.
Thanks!

2

You have already identified one solution (an auxilary device object per
adapter).

Another solution is to design your IOCTL arguments to (think InputBuffer) to
specify the adapter on which to operate.

To gain access to the adapter, you could use whatever ‘selector’ you have in
the IOCTL ‘parameters’ and search your adapter list (while holding the lock,
of course) for the appropriate adapter. RW locks are particularly useful
here since you only need ‘read’ access to the list.

The last bit of advice I have is for you to research the idea of a device
namespace. Since your auxilary device is a ‘top level’ device, it is free
to define an arbitrary namespace and use the FxContext and FsContext2 fields
of the FILE_OBJECT associated with the device open to connect (and remember)
the miniport you wish to target. A more sophisticated reference counting
scheme may be required to assure that an IRP sent to operate on a miniport
that has been ‘removed’ will not cause your code to bugcheck.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Monday, February 27, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multiple NICs

This post expands on the adapter context issue discussed in the thread
“Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
Over the past few days I’ve been going through my driver and cleaned it up
tremendously based on the excellent advice I’ve received in this newsgroup.

Furthermore, I added support for multiple adapters by using a global,
spinlock-protected linked list containing the adapter context areas.

As stated earlier, my driver acts as a virtual network adapter which can
receive packets from a user-mode application and indicate them up to NDIS.
In the netvmini sample, Eliyas only registers a single, global device object
(not sure why, really) which is used by all adapter instances.
Now, if I send a packet down to the driver and multiple adapters are
running, which adapter should receive the IRP request? Earlier on, when I
was assuming only a single adapter would be installed, I would just insert
the IRP request in that adapter’s IRP safe-cancel queue.
I imagine one could register a device object for each adapter, but is this
the correct and desired approach?

Continuing on…
Imagine the above problem is solved; how do I gain access to the desired
adapter from the dispatch routine? Only the device object is passed as an
argument… This question is, of course, dependent on the solution above, and
such may be rendered superfluous.

Also, I’d like to take the opportunity to say a big thank you to the entire
community here. The excellent help is greatly appreciated.
Thanks!

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Wonderful. Exactly what I needed.

I guess the most obvious solution in my case would be to have a device
object per adapter, as I really only plan on having one instance running.
However, the problem then exists of pairing the device object with the
correct adapter context in the linked list. If I remember correctly, I can’t
use the DeviceExtension field in the device object as NDIS reserves it. What
would you suggest?

What are Read/Write locks? I tried looking them up in MSDN but with no luck
(apart from several unrelated articles, that is :] )

I’ll look up device namespaces. Might prove useful in the future.

Thanks!

“David R. Cattley” wrote in message news:xxxxx@ntdev…
You have already identified one solution (an auxilary device object per
adapter).

Another solution is to design your IOCTL arguments to (think InputBuffer) to
specify the adapter on which to operate.

To gain access to the adapter, you could use whatever ‘selector’ you have in
the IOCTL ‘parameters’ and search your adapter list (while holding the lock,
of course) for the appropriate adapter. RW locks are particularly useful
here since you only need ‘read’ access to the list.

The last bit of advice I have is for you to research the idea of a device
namespace. Since your auxilary device is a ‘top level’ device, it is free
to define an arbitrary namespace and use the FxContext and FsContext2 fields
of the FILE_OBJECT associated with the device open to connect (and remember)
the miniport you wish to target. A more sophisticated reference counting
scheme may be required to assure that an IRP sent to operate on a miniport
that has been ‘removed’ will not cause your code to bugcheck.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
Sent: Monday, February 27, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Multiple NICs

This post expands on the adapter context issue discussed in the thread
“Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
Over the past few days I’ve been going through my driver and cleaned it up
tremendously based on the excellent advice I’ve received in this newsgroup.

Furthermore, I added support for multiple adapters by using a global,
spinlock-protected linked list containing the adapter context areas.

As stated earlier, my driver acts as a virtual network adapter which can
receive packets from a user-mode application and indicate them up to NDIS.
In the netvmini sample, Eliyas only registers a single, global device object
(not sure why, really) which is used by all adapter instances.
Now, if I send a packet down to the driver and multiple adapters are
running, which adapter should receive the IRP request? Earlier on, when I
was assuming only a single adapter would be installed, I would just insert
the IRP request in that adapter’s IRP safe-cancel queue.
I imagine one could register a device object for each adapter, but is this
the correct and desired approach?

Continuing on…
Imagine the above problem is solved; how do I gain access to the desired
adapter from the dispatch routine? Only the device object is passed as an
argument… This question is, of course, dependent on the solution above, and
such may be rendered superfluous.

Also, I’d like to take the opportunity to say a big thank you to the entire
community here. The excellent help is greatly appreciated.
Thanks!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Anyone…?

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Wonderful. Exactly what I needed.
>
> I guess the most obvious solution in my case would be to have a device
> object per adapter, as I really only plan on having one instance running.
> However, the problem then exists of pairing the device object with the
> correct adapter context in the linked list. If I remember correctly, I
can’t
> use the DeviceExtension field in the device object as NDIS reserves it.
What
> would you suggest?
>
> What are Read/Write locks? I tried looking them up in MSDN but with no
luck
> (apart from several unrelated articles, that is :] )
>
> I’ll look up device namespaces. Might prove useful in the future.
>
> Thanks!
>
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
> You have already identified one solution (an auxilary device object per
> adapter).
>
> Another solution is to design your IOCTL arguments to (think InputBuffer)
to
> specify the adapter on which to operate.
>
> To gain access to the adapter, you could use whatever ‘selector’ you have
in
> the IOCTL ‘parameters’ and search your adapter list (while holding the
lock,
> of course) for the appropriate adapter. RW locks are particularly useful
> here since you only need ‘read’ access to the list.
>
> The last bit of advice I have is for you to research the idea of a device
> namespace. Since your auxilary device is a ‘top level’ device, it is free
> to define an arbitrary namespace and use the FxContext and FsContext2
fields
> of the FILE_OBJECT associated with the device open to connect (and
remember)
> the miniport you wish to target. A more sophisticated reference counting
> scheme may be required to assure that an IRP sent to operate on a miniport
> that has been ‘removed’ will not cause your code to bugcheck.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
> Sent: Monday, February 27, 2006 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Multiple NICs
>
> This post expands on the adapter context issue discussed in the thread
> “Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
> Over the past few days I’ve been going through my driver and cleaned it up
> tremendously based on the excellent advice I’ve received in this
newsgroup.
>
> Furthermore, I added support for multiple adapters by using a global,
> spinlock-protected linked list containing the adapter context areas.
>
> As stated earlier, my driver acts as a virtual network adapter which can
> receive packets from a user-mode application and indicate them up to NDIS.
> In the netvmini sample, Eliyas only registers a single, global device
object
> (not sure why, really) which is used by all adapter instances.
> Now, if I send a packet down to the driver and multiple adapters are
> running, which adapter should receive the IRP request? Earlier on, when I
> was assuming only a single adapter would be installed, I would just insert
> the IRP request in that adapter’s IRP safe-cancel queue.
> I imagine one could register a device object for each adapter, but is this
> the correct and desired approach?
>
> Continuing on…
> Imagine the above problem is solved; how do I gain access to the desired
> adapter from the dispatch routine? Only the device object is passed as an
> argument… This question is, of course, dependent on the solution above,
and
> such may be rendered superfluous.
>
> Also, I’d like to take the opportunity to say a big thank you to the
entire
> community here. The excellent help is greatly appreciated.
> Thanks!
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>

5

Read/write locks: http://www.osronline.com/ddkx/network/103ndisx_2tiq.htm

DeviceExtension: Nope, cannot play with the DeviceExtension. NDIS owns it
and hides it.

Device Namespaces:
http://www.microsoft.com/whdc/driver/tips/DevNamespace.mspx

What you are trying to do is not that difficult if you just stop trying to
assocate yet another device object with every adapter. It is overkill and
unecessary. You only need to associate an open FILE_OBJECT with each
adapter. The PFILE_OBJECT is available in each IRP and thus mapping to the
correct adapter is trivial (assuming you take care to deal with the adapter
being removed before the FILE_OBJECT is closed). If you don’t want to deal
with associating a FILE_OBJECT with the Adapter at IRP_MJ_CREATE time, then,
option (b) is to put name of the adapter into every request
(IRP_MJ_DEVICE_CONTROL) as part of the InputBuffer and ‘lookup’ the adapter
for each request.

Even if you do feel compelled to have a DeviceObject per adapter, the only
place really to sort out the association between the auxilary device object
and the adapter is on IRP_MJ_CREATE. You have the name of the auxilary
device at that time and presumabley that is related in some meaningful way
to the name of the miniport device. During IRP_MJ_CREATE you need to figure
out what miniport / adapter and save the correspondence between the
DEVICE_OBJECT/FILE_OBJECT <-> ADAPTER and save it somewhere. You can save
it in the FILE_OBJECT::FsContext which is particularly nice or you can take
the hard route and try to save it in the ADAPTER object and forever have to
look it up ‘backwards’ for each request.

I would hazard to guess that the reason you did not get any more responses
to the post was essentially because there are not too many more ‘answers’ to
the original question which will stay within the ‘NDIS’ boundaries.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
Sent: Thursday, March 02, 2006 1:29 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Multiple NICs

Anyone…?

“S?ren Dreijer” wrote in message news:xxxxx@ntdev…
> Wonderful. Exactly what I needed.
>
> I guess the most obvious solution in my case would be to have a device
> object per adapter, as I really only plan on having one instance running.
> However, the problem then exists of pairing the device object with the
> correct adapter context in the linked list. If I remember correctly, I
can’t
> use the DeviceExtension field in the device object as NDIS reserves it.
What
> would you suggest?
>
> What are Read/Write locks? I tried looking them up in MSDN but with no
luck
> (apart from several unrelated articles, that is :] )
>
> I’ll look up device namespaces. Might prove useful in the future.
>
> Thanks!
>
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
> You have already identified one solution (an auxilary device object
> per adapter).
>
> Another solution is to design your IOCTL arguments to (think
> InputBuffer)
to
> specify the adapter on which to operate.
>
> To gain access to the adapter, you could use whatever ‘selector’ you
> have
in
> the IOCTL ‘parameters’ and search your adapter list (while holding the
lock,
> of course) for the appropriate adapter. RW locks are particularly useful
> here since you only need ‘read’ access to the list.
>
> The last bit of advice I have is for you to research the idea of a
> device namespace. Since your auxilary device is a ‘top level’ device,
> it is free to define an arbitrary namespace and use the FxContext and
> FsContext2
fields
> of the FILE_OBJECT associated with the device open to connect (and
remember)
> the miniport you wish to target. A more sophisticated reference
> counting scheme may be required to assure that an IRP sent to operate
> on a miniport that has been ‘removed’ will not cause your code to
bugcheck.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of S?ren Dreijer
> Sent: Monday, February 27, 2006 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Multiple NICs
>
> This post expands on the adapter context issue discussed in the thread
> “Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
> Over the past few days I’ve been going through my driver and cleaned
> it up tremendously based on the excellent advice I’ve received in this
newsgroup.
>
> Furthermore, I added support for multiple adapters by using a global,
> spinlock-protected linked list containing the adapter context areas.
>
> As stated earlier, my driver acts as a virtual network adapter which
> can receive packets from a user-mode application and indicate them up to
NDIS.
> In the netvmini sample, Eliyas only registers a single, global device
object
> (not sure why, really) which is used by all adapter instances.
> Now, if I send a packet down to the driver and multiple adapters are
> running, which adapter should receive the IRP request? Earlier on,
> when I was assuming only a single adapter would be installed, I would
> just insert the IRP request in that adapter’s IRP safe-cancel queue.
> I imagine one could register a device object for each adapter, but is
> this the correct and desired approach?
>
> Continuing on…
> Imagine the above problem is solved; how do I gain access to the
> desired adapter from the dispatch routine? Only the device object is
> passed as an argument… This question is, of course, dependent on the
> solution above,
and
> such may be rendered superfluous.
>
> Also, I’d like to take the opportunity to say a big thank you to the
entire
> community here. The excellent help is greatly appreciated.
> Thanks!
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

Ah, I see. I was thinking about making a hash table of some sort and then
look up the adapter from the device object. However, storing a pointer to
the adapter in the IO_STACK_LOCATION’s FileObject->FsContext field just
seems so much faster and better.

The PFILE_OBJECT is available in each IRP and thus mapping to the
correct adapter is trivial (assuming you take care to deal with the
adapter
being removed before the FILE_OBJECT is closed).

Indeed. Perhaps a better approach than storing a pointer to the adapter
context in the FILE_OBJECT would be to store a pointer to a global structure
which reference counts each NIC. That way one could easily check if the
adapter’s memory is still valid.

I would hazard to guess that the reason you did not get any more responses
to the post was essentially because there are not too many more ‘answers’
to
the original question which will stay within the ‘NDIS’ boundaries.

Right, but I just missed the coupling between the device object and the
adapter, which you so nicely presented below :slight_smile:

Thanks a bunch!

“David R. Cattley” wrote in message news:xxxxx@ntdev…
Read/write locks: http://www.osronline.com/ddkx/network/103ndisx_2tiq.htm

DeviceExtension: Nope, cannot play with the DeviceExtension. NDIS owns it
and hides it.

Device Namespaces:
http://www.microsoft.com/whdc/driver/tips/DevNamespace.mspx

What you are trying to do is not that difficult if you just stop trying to
assocate yet another device object with every adapter. It is overkill and
unecessary. You only need to associate an open FILE_OBJECT with each
adapter. The PFILE_OBJECT is available in each IRP and thus mapping to the
correct adapter is trivial (assuming you take care to deal with the adapter
being removed before the FILE_OBJECT is closed). If you don’t want to deal
with associating a FILE_OBJECT with the Adapter at IRP_MJ_CREATE time, then,
option (b) is to put name of the adapter into every request
(IRP_MJ_DEVICE_CONTROL) as part of the InputBuffer and ‘lookup’ the adapter
for each request.

Even if you do feel compelled to have a DeviceObject per adapter, the only
place really to sort out the association between the auxilary device object
and the adapter is on IRP_MJ_CREATE. You have the name of the auxilary
device at that time and presumabley that is related in some meaningful way
to the name of the miniport device. During IRP_MJ_CREATE you need to figure
out what miniport / adapter and save the correspondence between the
DEVICE_OBJECT/FILE_OBJECT <-> ADAPTER and save it somewhere. You can save
it in the FILE_OBJECT::FsContext which is particularly nice or you can take
the hard route and try to save it in the ADAPTER object and forever have to
look it up ‘backwards’ for each request.

I would hazard to guess that the reason you did not get any more responses
to the post was essentially because there are not too many more ‘answers’ to
the original question which will stay within the ‘NDIS’ boundaries.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
Sent: Thursday, March 02, 2006 1:29 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Multiple NICs

Anyone…?

“Søren Dreijer” wrote in message news:xxxxx@ntdev…
> Wonderful. Exactly what I needed.
>
> I guess the most obvious solution in my case would be to have a device
> object per adapter, as I really only plan on having one instance running.
> However, the problem then exists of pairing the device object with the
> correct adapter context in the linked list. If I remember correctly, I
can’t
> use the DeviceExtension field in the device object as NDIS reserves it.
What
> would you suggest?
>
> What are Read/Write locks? I tried looking them up in MSDN but with no
luck
> (apart from several unrelated articles, that is :] )
>
> I’ll look up device namespaces. Might prove useful in the future.
>
> Thanks!
>
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
> You have already identified one solution (an auxilary device object
> per adapter).
>
> Another solution is to design your IOCTL arguments to (think
> InputBuffer)
to
> specify the adapter on which to operate.
>
> To gain access to the adapter, you could use whatever ‘selector’ you
> have
in
> the IOCTL ‘parameters’ and search your adapter list (while holding the
lock,
> of course) for the appropriate adapter. RW locks are particularly useful
> here since you only need ‘read’ access to the list.
>
> The last bit of advice I have is for you to research the idea of a
> device namespace. Since your auxilary device is a ‘top level’ device,
> it is free to define an arbitrary namespace and use the FxContext and
> FsContext2
fields
> of the FILE_OBJECT associated with the device open to connect (and
remember)
> the miniport you wish to target. A more sophisticated reference
> counting scheme may be required to assure that an IRP sent to operate
> on a miniport that has been ‘removed’ will not cause your code to
bugcheck.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Søren Dreijer
> Sent: Monday, February 27, 2006 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Multiple NICs
>
> This post expands on the adapter context issue discussed in the thread
> “Debugging DRIVER_IRQL_NOT_LESS_OR_EQUAL”.
> Over the past few days I’ve been going through my driver and cleaned
> it up tremendously based on the excellent advice I’ve received in this
newsgroup.
>
> Furthermore, I added support for multiple adapters by using a global,
> spinlock-protected linked list containing the adapter context areas.
>
> As stated earlier, my driver acts as a virtual network adapter which
> can receive packets from a user-mode application and indicate them up to
NDIS.
> In the netvmini sample, Eliyas only registers a single, global device
object
> (not sure why, really) which is used by all adapter instances.
> Now, if I send a packet down to the driver and multiple adapters are
> running, which adapter should receive the IRP request? Earlier on,
> when I was assuming only a single adapter would be installed, I would
> just insert the IRP request in that adapter’s IRP safe-cancel queue.
> I imagine one could register a device object for each adapter, but is
> this the correct and desired approach?
>
> Continuing on…
> Imagine the above problem is solved; how do I gain access to the
> desired adapter from the dispatch routine? Only the device object is
> passed as an argument… This question is, of course, dependent on the
> solution above,
and
> such may be rendered superfluous.
>
> Also, I’d like to take the opportunity to say a big thank you to the
entire
> community here. The excellent help is greatly appreciated.
> Thanks!
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer