lwip-devel
[Top][All Lists]
Advanced

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

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


From: address@hidden
Subject: Re: [lwip-devel] Re: [task #7040] Work on tcp_enqueue
Date: Sun, 01 Feb 2009 12:49:15 +0100
User-agent: Thunderbird 2.0.0.19 (Macintosh/20081209)

Jakob Stoklund Olesen wrote:
[... tcp_sent_callback() ...]
It worked most of the time, but TCP retransmissions caused bad stuff to
happen. It was either a bug in my code, or the sum of callback lengths
did not match what had been actually sent.

Has anybody used non-copy tcp_write with memory that must be reclaimed?
Can it be done?

I suppose that could be a bug in tcp_sent_callback. I've never tested it, but I always expected it to be called when data has been ACKed (which means it should not be retransmitted again). If so, retransmission should not have an impact.

Sounds good. The first step would be to split tcp_enqueue in two - data
and options. I will have a go at that. tcp_enqueue is not considered part
of the API, right? It is only in tcp.h because it is called from tcp.c,
tcp_in.c, and tcp_out.c.

You are right on tcp_enqueue: it is only used internally. But you have to pay attention to the fact that data _and_ options could be enqueued; I cannot remember if this happens somewhere right now, or if the current implementation of tcp_write allows it...

As for checksumming: You wouldn't need to extend the pbuf with a
checksum field. For this case, the checksum field in the TCP header
could be kept up to date when a segment is created and extended. A
checksum field of 0xffff would tell tcp_output to calculate it. (That
value is never returned by inet_chksum_*)

That would mean it only works with TCP and nothing else. For our current discussion, that's good enough, of course. But if we implement that, I'd like to do it in a way resuable for UDP: Since UDP only takes pbufs, we could allow application code to fill these pbufs with checksum_on_copy or something.

Simon, do you have a checksumming memcpy? Is it part of a patch, I
missed?

I do have writen one (although I wouldn't find it right now), but that was written for a NIOS-II with a custom instruction to speed up the process. This would be of very little use to any other processor...

I am looking for the equivalent of:

u16_t
inet_chksum_memcpy(void *dst, const void *src, size_t len)
{
  memcpy(dst, src, len);
  return inet_chksum(src, len);
}

(Actually, the simple implementation would work pretty well for me. I
have data caches.)

Of course that depends on the cache size, but it could be a reasonably default implementation, since there is always the potential speedup of calling the two functions as one (because of cache).

This is reasonable. I would suggest creating a third tcp_enqueue_pbuf
variant.

tcp_enqueue_pbuf could be used by the 'old' tcp_enqueue, after allocating and filling the pbufs.

The allocation stuff is tricky. Should the allocation depend on the
amount of space in the last unsent segment? Should a chain be allocated
if more than an MSS is requested?

Presumably, the application is going to generate data directly into an
allocated chain. That probably means some requirements on alignment of
both payload pointers and lengths.

I like Jonathan's idea for that: something like 'tcp_alloc_pbuf(pcb, netif, pbuf_type, len)'. This way both the already queued pbufs of the pcb as well as the memory or chain constraints of the MAC can have an impact on the allocated pbufs.

Calling tcp_enqueue_pbuf would still work with any pbuf as long as there is room for header and it doesn't exceed the MSS: you could still get strange, non-optimal segment sizes, but at the advantage of having single-pbuf segments and supporting zero-copy.


Simon




reply via email to

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