Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[Mason]

Kieran Mansley wrote:

> On Tue, 2011-10-11 at 16:50 +0200, Mason wrote:
>>
>> So the hardware + driver is indeed able to handle the load.
>>
>> I must be doing something wrong in my driver when I pass
>> data to lwip.
> 
> In this UDP test did you use lwIP to process the UDP traffic, or was it
> just a test that interfaced directly to your driver?

In the UDP test, any frame larger than 1500 bytes was
not passed to lwip. The bogus ACK was sent directly
from the RX context instead.

>> In the RX part, I copy the incoming frame :
>>
>>     packet_descriptor *desc = wait_for_next_packet( );
>>     /*** PROCESS THE PACKET ***/
>>     struct pbuf *pbuf = pbuf_alloc(PBUF_RAW, desc->length, PBUF_RAM);
>>     memcpy(pbuf->payload, desc->buffer, desc->length);
>>     mynetif->input(pbuf, mynetif);
>>
>> I've disabled TCPIP checksum verification with
>> #define CHECKSUM_CHECK_TCP 0
> 
> Yikes!  I hope this is just for experimenting to find the source of your
> performance problems, rather than something you intend to disable
> permanently.

Of course. Bill suggested this feature might be a bottle-neck, so
I disabled it to see if it had an impact. (In my case, it didn't.)

>> In the TX part, I copy the outgoing pbuf :
>>
>>   packet_descriptor *desc = get_packet_descriptor( );
>>   assert(p->next == NULL);
>>   memcpy(desc->buffer, p->payload, p->len);
>>   desc->length = p->len;
>>   // add desc to list of frames to send
> 
> Did your UDP test involve copying data to/from descriptors like this?

No.

> If not, this is likely to be a large part of the explanation why the UDP
> test was fast, but your original experiments were slow.

In my TCP tests, I did suspect there was excessive copying,
so instead of copying the whole frame, I only copied the
first 80 bytes. It didn't change much.

I've run so many tests that I tend to forget what was done
and why. I will run the UDP test with a socket-based reader.

-- 
Regards.