Hello,
I have been a lurker on this netdev list for the last 6 months and have
learned a lot by simply watching the e-mails go by. I am quite
impressed with the knowledge floating around out there. Now I need to
ask for some advice on how to approach my current problem.
I am developing a device driver that supports an adapter that has its
own TCP/UDP/ICMP/IP stack onboard in silicon (some may refer to this as
a transport offload engine). My challenge is to have the hardware
stack(s) co-exist with the Linux software stack which will have to be
used to support "conventional" NICs. Since we want this to be
transparent to users at the socket layer (the interface to the chip is
actual socket calls - socket, bind, listen, etc. along with support
functions and methods for transmitting raw packets), I believe this to
be a non-trivial endeavour. Creating my own protocol family is the easy
way out, but not very useful to the tons of existing socket software.
I have done some research into the 2.2.14 kernel some time back and now
need to move forward with hooking in to the kernel to support my
"hardware" stack. The driver work that I have done so far in supporting
"conventional" NIC operation has been completed for 2.2.14. You are
probably asking why I have not graduated to 2.4 kernels.... my responses
would be 1) lack of time in trying to get something to work as it is
and 2) sticking with commercially available distributions when I started
this project.
With this background information, my questions are as follows:
1) Has anyone looked into the problem of supporting multiple stacks in
Linux (the existing software stack with one or more hardware stacks)?
If so, are the research results available?
2) Is now the time to switch from 2.2.14 to 2.4.x to simplify my life?
This will involve converting the existing framework that I have for
supporting "conventional" mode.
3) Where is the best place to hook in? I could intercept sys_* calls or
I could hook in at the specific protocol (tcp, udp, raw). My feeling is
it will be a combination of the two.
Multiple stacks introduce interesting problems. When a user app opens a
socket, a socket has to be opened on all stacks and simultaneous ops
have to be done to each until the socket is bound. Once bound, the
others need to be cleaned up. I am sure this is just the tip of the
iceberg.
Any comments and suggestions would be greatly appreciated.
Greg Parrott
Optical Area Networking
Lucent Technologies
919-838-6095
http://www.lucent-optical.com/oan
|