[lwip-users] Re: [lwip] lwIP on DSPs

[Adam Dunkels]

Hi Bill!

On Tuesday 11 December 2001 14.05, you wrote:
> Congratulations!  And whoopee too.  I had to drop the port a couple
> of weeks ago and go back to fixing a commercial stack because of
> project time constraints.  Even at this point we only have UDP
> working.  TCP is still producing incorrect checksums on received
> packets.

Did you go for the CMX stack? Weird that UDP works while TCP does not. They 
usually share the same checksumming functions.

> I have pondered more on your approach of packing everything into 16
> bit words (and/or chars in this case) instead of just the lower 8
> bits of the 16 bit chars of the DSP.  If you have been able to prod
> the stack itself into accepting this, great!  It uses less memory and
> probably less code space too.  The user is going to have to be very
> careful in the manner in which data are submitted to and retrieved
> from the stack.  It looks like it is going to have to be packed as it
> goes in and sorted as it comes out.  I've been doing it the other way
> around with the implementation I'm using (only the lower 8 bits of 16
> bit chars).  A for instance of this is, given the following:
>   char string[] = "This is a test string.";
> the compiler only uses the lower 8 bits of each 16 bit word.  Or to
> be more exact, it uses 1 char per character, just as it should.  If
> this string were directly submitted and sent to a "normal" stack, it
> would be received with NULLs placed between each ASCII character.
> While I haven't downloaded and looked at the new version, I hope
> issues like this are addressed.  Thinking out loud - maybe it is
> possible to place a packed/not-packed flag in the pbuf header to
> provide a signal to the stack as to the data format.  Or maybe a pair
> of pack/unpack routines to assist in submitting and retrieving data
> to and from the stack.  -- just thoughts.

This issue falls between being application specific and being architecture 
specific. The application could pack/unpack when receiving/sending data. On 
the other hand, this will probably be one of the bottlenecks of the system 
and one optimization would be to to the conversion while calculating the 
checksum. The checksum routines should really be architecture specific anyway 
(and written in optimized assembler). The disadvantage with this approach is 
that the result of the packing would have to be stored in another buffer 
since the checksum is recalculated when retransmitting. Extra logic to deal 
with this extra buffer would have to be used as well. 

The problem with any approach other than the application doing the 
packing/unpacking is that it would require changes to the lwIP code. If the 
pbuf flag field would be used, the tcp_enqueue() function would need to be 
changed to support this. Also, since the same checksum functions is used for 
both generating and checking the checksum, changes would have to be made to 
the code that calls the checksum functions.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]