Hi Gurus,
How can I implement TCP/IP offloading in Windows ?.
I have to implement full offloading. NDIS provide some partial offloading fecilities, like segmentation, checksum nd security. But I have to move almost all of the protocol implementation to my hardware. Is it possible with my own NDIS protocol, intermediate and miniport drivers ?.
Thanks in advance…
Sisimon
Hey! Sisimon,
The next version of MS Windows that Long Horn, is having all that facility. This Kernel is havin NDIS 6.0 which is more advanced and functionalities supporting. But if you want this to be implemented then just think in the wierd directions you will be able to do that. 
You have two options:
1.Wait For Ndis 6.0,
or
Go for your own implementation in the kernel (it suits to me).
Good Luck,
From: “Sisimon”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] TCP/IP Offloading and NDIS
>Date: Tue, 2 Mar 2004 19:33:44 +0530
>
>Hi Gurus,
>
> How can I implement TCP/IP offloading in Windows ?.
> I have to implement full offloading. NDIS provide some partial offloading fecilities, like segmentation, checksum nd security. But I have to move almost all of the protocol implementation to my hardware. Is it possible with my own NDIS protocol, intermediate and miniport drivers ?.
>
>Thanks in advance…
>Sisimon
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Contact brides & grooms FREE! Only on www.shaadi.com. Register now!
Thanks Yatindra,
But LongHorn is scheduled to release on 2005 end or 2006 beginning. I can’t wait for that.
And my own implementation of kernel, it not much big deal :), but the source is not open.(some smart guys did it in Linux)
I am new to NDIS, is there any why to skip the traditional TCP/IP driver and can I plug my own protocol driver to the driver stack ?. If it is possible I can implement full TCP/IP offloading, because my hardware can handle most of the TCP/IP implementation except some caching. Does the TCP/IP protocol driver source code is open with DDK ?.
Thanks
Sisimon
----- Original Message -----
From: yatindra vaishnav
To: Windows System Software Devs Interest List
Sent: Tuesday, March 02, 2004 8:14 PM
Subject: RE: [ntdev] TCP/IP Offloading and NDIS
Hey! Sisimon,
The next version of MS Windows that Long Horn, is having all that facility. This Kernel is havin NDIS 6.0 which is more advanced and functionalities supporting. But if you want this to be implemented then just think in the wierd directions you will be able to do that.
You have two options:
1.Wait For Ndis 6.0,
or
Go for your own implementation in the kernel (it suits to me).
Good Luck,
>From: “Sisimon”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] TCP/IP Offloading and NDIS
>Date: Tue, 2 Mar 2004 19:33:44 +0530
>
>Hi Gurus,
>
> How can I implement TCP/IP offloading in Windows ?.
> I have to implement full offloading. NDIS provide some partial offloading fecilities, like segmentation, checksum nd security. But I have to move almost all of the protocol implementation to my hardware. Is it possible with my own NDIS protocol, intermediate and miniport drivers ?.
>
>Thanks in advance…
>Sisimon
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
------------------------------------------------------------------------------
Contact brides & grooms FREE! Only on www.shaadi.com. Register now! —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
On Tue, 2004-03-02 at 09:08, Sisimon wrote:
I am new to NDIS, is there any why to skip the traditional TCP/IP
driver and can I plug my own protocol driver to the driver stack ?. If
it is possible I can implement full TCP/IP offloading, because my
hardware can handle most of the TCP/IP implementation except some
caching. Does the TCP/IP protocol driver source code is open with DDK
?
You could indeed build your own protocol driver with a TDI upper edge,
and then back it up directly to hardware. It would be just like a
normal WDM driver, except it would probably export named devices that
implement the TDI API. I don’t know whether or not this could be
signed.
Note that unless you want to disable the in-box tcpip.sys driver, you’ll
have to name your devices differently than the tcpip.sys protocol
driver. If you do that, there are other considerations to getting
sockets-style access to the driver, like writing a winsock provider.
Sounds like a fun project.
-sd
Thanks Steave. Is there any sample TDI Hooks source code available?
And it is not a fun project, some vendors already have this type almost full
TCP/IP offloading products in Windows.
They use TDI Hooks (I think). And Microsoft is also planning to provide full
TCP/IP offloading facilities in LongHorn(named ‘Chimney’). But I can’t wait
for that much amount of time.
And if I skip the traditional TCP/IP stack, many other management
application will not work, because they have their own intermediate drivers
and these drivers not aware of the new stack.
thanks
sisimon
----- Original Message -----
From: “Steve Dispensa”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, March 02, 2004 9:19 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
> On Tue, 2004-03-02 at 09:08, Sisimon wrote:
> > I am new to NDIS, is there any why to skip the traditional TCP/IP
> > driver and can I plug my own protocol driver to the driver stack ?. If
> > it is possible I can implement full TCP/IP offloading, because my
> > hardware can handle most of the TCP/IP implementation except some
> > caching. Does the TCP/IP protocol driver source code is open with DDK
> > ?
>
> You could indeed build your own protocol driver with a TDI upper edge,
> and then back it up directly to hardware. It would be just like a
> normal WDM driver, except it would probably export named devices that
> implement the TDI API. I don’t know whether or not this could be
> signed.
>
> Note that unless you want to disable the in-box tcpip.sys driver, you’ll
> have to name your devices differently than the tcpip.sys protocol
> driver. If you do that, there are other considerations to getting
> sockets-style access to the driver, like writing a winsock provider.
>
> Sounds like a fun project.
>
> -sd
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Hi Sisimon,
It is possible and 100% possible.
Good Luck,
From: “Sisimon”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>Date: Tue, 2 Mar 2004 21:50:34 +0530
>
>
>Thanks Steave. Is there any sample TDI Hooks source code available?
>And it is not a fun project, some vendors already have this type almost full
>TCP/IP offloading products in Windows.
>They use TDI Hooks (I think). And Microsoft is also planning to provide full
>TCP/IP offloading facilities in LongHorn(named ‘Chimney’). But I can’t wait
>for that much amount of time.
>
>And if I skip the traditional TCP/IP stack, many other management
>application will not work, because they have their own intermediate drivers
>and these drivers not aware of the new stack.
>
>thanks
>sisimon
>
>
>----- Original Message -----
>From: “Steve Dispensa”
>To: “Windows System Software Devs Interest List”
>Sent: Tuesday, March 02, 2004 9:19 PM
>Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>
>
> > On Tue, 2004-03-02 at 09:08, Sisimon wrote:
> > > I am new to NDIS, is there any why to skip the traditional TCP/IP
> > > driver and can I plug my own protocol driver to the driver stack ?. If
> > > it is possible I can implement full TCP/IP offloading, because my
> > > hardware can handle most of the TCP/IP implementation except some
> > > caching. Does the TCP/IP protocol driver source code is open with DDK
> > > ?
> >
> > You could indeed build your own protocol driver with a TDI upper edge,
> > and then back it up directly to hardware. It would be just like a
> > normal WDM driver, except it would probably export named devices that
> > implement the TDI API. I don’t know whether or not this could be
> > signed.
> >
> > Note that unless you want to disable the in-box tcpip.sys driver, you’ll
> > have to name your devices differently than the tcpip.sys protocol
> > driver. If you do that, there are other considerations to getting
> > sockets-style access to the driver, like writing a winsock provider.
> >
> > Sounds like a fun project.
> >
> > -sd
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Post Classifieds on MSN classifieds. Buy and Sell on MSN Classifieds.
On Tue, 2004-03-02 at 10:20, Sisimon wrote:
Thanks Steave. Is there any sample TDI Hooks source code available?
Thomas Divine has a sample that he sells on his website. I believe the
address is www.pcausa.com. His stuff is well-tested and well-supported.
Apart from that, it’s not a conceptually difficult driver to write.
There was just a (short) thread about this on the pcausa mailing list,
also available on the above website.
And it is not a fun project, some vendors already have this type almost full
TCP/IP offloading products in Windows.
They use TDI Hooks (I think).
And if I skip the traditional TCP/IP stack, many other management
application will not work, because they have their own intermediate drivers
and these drivers not aware of the new stack.
Yeah, you have to pick what to break. I’d say that, in general, the
more traditional high-level functionality you offload to the card, the
more broken things will get. I’d really need to know a lot more about
the card to recommend anything, but as a general principle, try very
hard to not upset the standard TDI/NDIS model. The more closely you can
fit your solution to that model, the more compatible you’ll be. And the
more signable, if that matters.
-sd
>
Yeah, you have to pick what to break. I’d say that, in general, the
more traditional high-level functionality you offload to the card, the
more broken things will get. I’d really need to know a lot more about
the card to recommend anything, but as a general principle, try very
hard to not upset the standard TDI/NDIS model. The more closely you can
fit your solution to that model, the more compatible you’ll be. And the
more signable, if that matters.
Hey! It is quite possible to implement such a solution and that is too that can withstand with the normal TCPIP stack of the Windows, and i believe there will not be anything which is goin to be broken.
And believe me Steve the implementation of the TOE is totally implementoation dependent and every vendor is having their own implementation if u get idea of one it cant be fitted in the case of others.
Good Luck,
INDIA TODAY @ Rs. 5 + a free gift ! Subcribe Now …
The idea is very popular in Linux world and it is hard to implement in Windows, bcos NDIS provide some limited interfaces to do these type stuffs. And I am writing according to the TOE implementation in Linux. The TOEs has almost full functionalities of TCP/IP. But usually it has limited memory capacity to reduce cost. So some kind of caching should implement in driver level. And one thing is sure, I have to break the normal TCP/IP stack. And my problem is, exactly where I can break the traditional tcp/ip stack.
And with my limited knowledge, Microsoft chimney provide interfaces to offload data flow(not connection establishment/termination/error handling). The connection establishment/termination stuffs will be in host OS protocol stack itself. So for connection establishment/closing it will goes through the traditional protocol stack and while send/receive packets the ASIC will do the actual work. But I have to offload all tasks including connection establishment/termination.
regs
sisi
----- Original Message -----
From: yatindra vaishnav
To: Windows System Software Devs Interest List
Sent: Wednesday, March 03, 2004 2:02 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>Yeah, you have to pick what to break. I’d say that, in general, the
>more traditional high-level functionality you offload to the card, the
>more broken things will get. I’d really need to know a lot more about
>the card to recommend anything, but as a general principle, try very
>hard to not upset the standard TDI/NDIS model. The more closely you can
>fit your solution to that model, the more compatible you’ll be. And the
>more signable, if that matters.
>
Hey! It is quite possible to implement such a solution and that is too that can withstand with the normal TCPIP stack of the Windows, and i believe there will not be anything which is goin to be broken.
And believe me Steve the implementation of the TOE is totally implementoation dependent and every vendor is having their own implementation if u get idea of one it cant be fitted in the case of others.
Good Luck,
------------------------------------------------------------------------------
INDIA TODAY @ Rs. 5 + a free gift ! Subcribe Now … —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hey! Sisimon,
Windows is not very hard u need to know just how to implement the things, with available resources. And i believe MS OS are enuff flexible to let us do that. And i beleive there will not be any problems.
Good Luck,
From: “Sisimon”
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>Date: Wed, 3 Mar 2004 15:13:28 +0530
>
>
>The idea is very popular in Linux world and it is hard to implement in Windows, bcos NDIS provide some limited interfaces to do these type stuffs. And I am writing according to the TOE implementation in Linux. The TOEs has almost full functionalities of TCP/IP. But usually it has limited memory capacity to reduce cost. So some kind of caching should implement in driver level. And one thing is sure, I have to break the normal TCP/IP stack. And my problem is, exactly where I can break the traditional tcp/ip stack.
>
>And with my limited knowledge, Microsoft chimney provide interfaces to offload data flow(not connection establishment/termination/error handling). The connection establishment/termination stuffs will be in host OS protocol stack itself. So for connection establishment/closing it will goes through the traditional protocol stack and while send/receive packets the ASIC will do the actual work. But I have to offload all tasks including connection establishment/termination.
>
>regs
>sisi
>
> ----- Original Message -----
> From: yatindra vaishnav
> To: Windows System Software Devs Interest List
> Sent: Wednesday, March 03, 2004 2:02 PM
> Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>
>
> >
> >Yeah, you have to pick what to break. I’d say that, in general, the
> >more traditional high-level functionality you offload to the card, the
> >more broken things will get. I’d really need to know a lot more about
> >the card to recommend anything, but as a general principle, try very
> >hard to not upset the standard TDI/NDIS model. The more closely you can
> >fit your solution to that model, the more compatible you’ll be. And the
> >more signable, if that matters.
> >
>
> Hey! It is quite possible to implement such a solution and that is too that can withstand with the normal TCPIP stack of the Windows, and i believe there will not be anything which is goin to be broken.
>
> And believe me Steve the implementation of the TOE is totally implementoation dependent and every vendor is having their own implementation if u get idea of one it cant be fitted in the case of others.
>
>
>
> Good Luck,
>
>
>
>
>
>
>------------------------------------------------------------------------------
> INDIA TODAY @ Rs. 5 + a free gift ! Subcribe Now … —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Skin is in! Bollywood is sizzling. Check out these hot pics!
You need your own kernel-mode driver for this hardware, which will expose some upper edge. You will also need a Winsock LSP in user mode which will call your driver via ReadFile/WriteFile/DeviceIoControl, and pass the calls down to usual MSAFD provider if the local IP address used belongs to a usual NIC and not your device.
If your kernel-mode code will export the TDI upper edge - then possibly you can re-use existing sockets implementation of AFD.SYS + MSAFD.DLL, and so you will need only the kernel-mode part + an MSAFD helper DLL (the sample source is in the DDK). Try this.
NDIS has nothing to do with this. TDI possibly can be used.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Sisimon
To: Windows System Software Devs Interest List
Sent: Tuesday, March 02, 2004 5:03 PM
Subject: [ntdev] TCP/IP Offloading and NDIS
Hi Gurus,
How can I implement TCP/IP offloading in Windows ?.
I have to implement full offloading. NDIS provide some partial offloading fecilities, like segmentation, checksum nd security. But I have to move almost all of the protocol implementation to my hardware. Is it possible with my own NDIS protocol, intermediate and miniport drivers ?.
Thanks in advance…
Sisimon
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Once more - this has nothing to do with NDIS.
NDIS (BTW, by far more feature-rich than its Linux counterpart who mandates the packets to be in-memory contiguous) suggests that you use the OS-supplied software IP stack. If this is not so - then sorry, you’re writing your own piece of code to manage your own hardware, which is not considered to be a network device by the rest of OS.
It will just handle the WinSock calls for one of the local IP addresses, and yes, “route print” will not display this address, and IP Helper APIs (which are wrappers around some IOCTLs leading to OS-supplied IP stack) will not work with it too.
IIRC this architecture is called WinSock Direct.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Sisimon
To: Windows System Software Devs Interest List
Sent: Wednesday, March 03, 2004 12:43 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
The idea is very popular in Linux world and it is hard to implement in Windows, bcos NDIS provide some limited interfaces to do these type stuffs. And I am writing according to the TOE implementation in Linux. The TOEs has almost full functionalities of TCP/IP. But usually it has limited memory capacity to reduce cost. So some kind of caching should implement in driver level. And one thing is sure, I have to break the normal TCP/IP stack. And my problem is, exactly where I can break the traditional tcp/ip stack.
And with my limited knowledge, Microsoft chimney provide interfaces to offload data flow(not connection establishment/termination/error handling). The connection establishment/termination stuffs will be in host OS protocol stack itself. So for connection establishment/closing it will goes through the traditional protocol stack and while send/receive packets the ASIC will do the actual work. But I have to offload all tasks including connection establishment/termination.
regs
sisi
----- Original Message -----
From: yatindra vaishnav
To: Windows System Software Devs Interest List
Sent: Wednesday, March 03, 2004 2:02 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>Yeah, you have to pick what to break. I’d say that, in general, the
>more traditional high-level functionality you offload to the card, the
>more broken things will get. I’d really need to know a lot more about
>the card to recommend anything, but as a general principle, try very
>hard to not upset the standard TDI/NDIS model. The more closely you can
>fit your solution to that model, the more compatible you’ll be. And the
>more signable, if that matters.
>
Hey! It is quite possible to implement such a solution and that is too that can withstand with the normal TCPIP stack of the Windows, and i believe there will not be anything which is goin to be broken.
And believe me Steve the implementation of the TOE is totally implementoation dependent and every vendor is having their own implementation if u get idea of one it cant be fitted in the case of others.
Good Luck,
----------------------------------------------------------------------------
INDIA TODAY @ Rs. 5 + a free gift ! Subcribe Now … —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Maxim, it is very helpful for me.
regs
sisi
----- Original Message -----
From: Maxim S. Shatskih
To: Windows System Software Devs Interest List
Sent: Thursday, March 04, 2004 6:11 AM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
Once more - this has nothing to do with NDIS.
NDIS (BTW, by far more feature-rich than its Linux counterpart who mandates the packets to be in-memory contiguous) suggests that you use the OS-supplied software IP stack. If this is not so - then sorry, you’re writing your own piece of code to manage your own hardware, which is not considered to be a network device by the rest of OS.
It will just handle the WinSock calls for one of the local IP addresses, and yes, “route print” will not display this address, and IP Helper APIs (which are wrappers around some IOCTLs leading to OS-supplied IP stack) will not work with it too.
IIRC this architecture is called WinSock Direct.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Sisimon
To: Windows System Software Devs Interest List
Sent: Wednesday, March 03, 2004 12:43 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
The idea is very popular in Linux world and it is hard to implement in Windows, bcos NDIS provide some limited interfaces to do these type stuffs. And I am writing according to the TOE implementation in Linux. The TOEs has almost full functionalities of TCP/IP. But usually it has limited memory capacity to reduce cost. So some kind of caching should implement in driver level. And one thing is sure, I have to break the normal TCP/IP stack. And my problem is, exactly where I can break the traditional tcp/ip stack.
And with my limited knowledge, Microsoft chimney provide interfaces to offload data flow(not connection establishment/termination/error handling). The connection establishment/termination stuffs will be in host OS protocol stack itself. So for connection establishment/closing it will goes through the traditional protocol stack and while send/receive packets the ASIC will do the actual work. But I have to offload all tasks including connection establishment/termination.
regs
sisi
----- Original Message -----
From: yatindra vaishnav
To: Windows System Software Devs Interest List
Sent: Wednesday, March 03, 2004 2:02 PM
Subject: Re: [ntdev] TCP/IP Offloading and NDIS
>Yeah, you have to pick what to break. I’d say that, in general, the
>more traditional high-level functionality you offload to the card, the
>more broken things will get. I’d really need to know a lot more about
>the card to recommend anything, but as a general principle, try very
>hard to not upset the standard TDI/NDIS model. The more closely you can
>fit your solution to that model, the more compatible you’ll be. And the
>more signable, if that matters.
>
Hey! It is quite possible to implement such a solution and that is too that can withstand with the normal TCPIP stack of the Windows, and i believe there will not be anything which is goin to be broken.
And believe me Steve the implementation of the TOE is totally implementoation dependent and every vendor is having their own implementation if u get idea of one it cant be fitted in the case of others.
Good Luck,
--------------------------------------------------------------------------
INDIA TODAY @ Rs. 5 + a free gift ! Subcribe Now … —
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@calsoftinc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com