[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kieran Mansley
Subject: Re: [lwip-users] TCP bandwidth limited by rate of ACKs
Date: Tue, 11 Oct 2011 16:00:24 +0100

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?

> > If the hardware
> > is really fast enough, you seem to have a bottleneck somewhere in
> > your code, supposedly either somewhere around your netif driver or
> in
> > your OS threading? If your netif driver uses PBUF_POOL for rx
> > packets, you might want to check that PBUF_POOL_BUFSIZE is large
> > enough to hold a complete frame.
> 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

Yikes!  I hope this is just for experimenting to find the source of your
performance problems, rather than something you intend to disable

> 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?
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]