RE: [lwip-users] Applications to TCP/IP offload

[Curt McDowell]

Thanks for the input, Jim.

 

>As for the performance improvement, that's a very significant question.  First, I think that it is important to ask what kind of performance improvement you seek.  If you are just seeking to offload the host, so that it can go on to do some other task faster, then you stand a reasonable chance of seeing that happen.  If you are ultimately seeking to increase TCP/IP throughput, that will be a more difficult road.

In our case, the host processor would be about 4 times as powerful as the coprocessor.  The coprocessor has some spare cycles, and it'll be there regardless of whether it ends up doing TOE.  The goal is simply to reduce CPU consumption on the host processor with no reduction in throughput. The MAC has no checksum acceleration, so that's actually one of the most important things to off-load.

 

 > I feel that your assessment of feasibility is sound and that your list of problems and their resolution is reasonably complete.  Something always shows up in implementation, and I'm sure that your project will be no exception, but I do think that your design is solid.
 

I'm finding that splitting the modules in the manner depicted is not so easy after all.  E.g., for efficiency reasons the top layer routine netconn_write() calls tcp_sndbuf(), which peeks in the bottom layer data structure.  It's tempting to just add a top layer to RPC the whole sockets API (but unfortunately, the tiny RTOS on the TOE processor would then need to support threads).
 
Regards,

Curt McDowell

Broadcom Corp.

 
Curt McDowell wrote:

Hi,

I'm looking into using lwIP as the basis for a TOE (TCP/IP offload engine).  If I understand correctly, the lwIP environment is implemented as one thread for the IP stack, and one thread for each application:

    APPLICATION THREAD                            IP STACK THREAD
App <-> Sockets <-> API-mux <------------> API-demux <-> Stack <-> netif
                            mbox transport

This architecture appears to lend itself fairly well to the following TOE implementation (actually, SOE, as it would be a full sockets offload):

         HOST PROCESSOR                     TOE ADAPTER W/ EMBEDDED CPU
+-------------+   +--------------+            +-------+   +----------+
| App using   |---| lwIP library |------------| lwIP  |---| Network  |--->
| sockets API |   | Sockets API  |  Hardware  | stack |   | hardware |
+-------------+   +--------------+    bus     +-------+   +----------+

- Does this assessment sound correct?
- Could a significant performance improvement be realized, compared to using a host-native IP stack?
- Is anyone else interested in this type of application?

The only problems that I see are with the mbox transport mechanism, in that it assumes a shared address space.

-  It would need to send the data, instead of pointers to the data.
-  It would need to send messages for event notifications instead of using callbacks.
- Message reception on either side of the hardware bus would be signaled through interrupts.

Thanks,
Curt McDowell
Broadcom Corp.