[lwip-devel] Re: [task #7040] Work on tcp_enqueue

[Jakob Stoklund Olesen]

"address@hidden" <address@hidden> writes:

[...]

> If we changed the API to only allow enqueueing prefilled pbufs, we'd
> always have every call to tcp_write 'waste' a pbuf.

I would want to keep tcp_write as well. I think that tcp_write_pbuf is
mostly useful for very specialized application code that can generate
data directly into a pbuf chain. In all other cases, you would
essentially be moving the copy from the stack to the application code /
adaptation layer.

A copy in tcp_enqueue can be tuned by calculating checksums on the fly,
allocating optimal pbufs for the MAC etc. A copy in the application code
is outside our control.

> I'd like to sum up what has to be / can be improved in tcp_write/_enqueue:
> - prevent segments with size less than MSS being sent when there's
> enough data enqueued
> - don't allocate more pbufs that we need
> - take care of MAC limitations (e.g. no pbuf chains, special pbuf
> length, etc.)
> - accept prefilled pbufs to prevent copying for applications where
> data is generated (can be generated directly into a pbuf)

- checksum-on-copy

Here is a plan:

1. Split tcp_enqueue in two: data+options.

2. Move checksumming from tcp_output_segment to tcp_enqueue. Some header
   fields are updated in tcp_output_segment. Update the checksum.

3. Use inet_chksum_memcpy to checksum on the fly. Incrementally update
   seg->tcphdr->chksum when adding data.

4. Allocate larger pbufs using clever strategy. pcb->unsent_tail_space
   holds the number of extra bytes available in the final pbuf of
   pcb->unsent.

I will try to find the time to implement these points. I probably won't
write tcp_write_pbuf. My own code won't be using it, and I cannot easily
test it.

> The first can be done by a simple change in tcp_enqueue
> (unfortunately, I don't have the time right now to check your patch,
> Jakob).

It looks like an alternative is in the pipeline, so don't waste your
time yet.

> The second could need a change in the API (need to know the fill
> status of the pbuf in the last segment),

Do you mean an extra field in tcp_pcb?

What are some common MAC DMA limitations when _transmitting_?
I can name two:

Blackfin EMAC can do a two-way split: headers+payload. Both must be
32-bit aligned.

Blackfin my-own-weird-board-to-board-link: Unlimited chain length, each
pbuf address and length must be 16-bit aligned.

I have not used the AT91SAM7X, but from the datasheet it looks like it
can do arbitrary scatter-gather DMA (on transmission at least).

/stoklund