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

[Jakob Stoklund Olesen]

"address@hidden" <address@hidden> writes:
> 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...

Not a problem, it is not allowed. From tcp_enqueue prolog:

  LWIP_ERROR("tcp_enqueue: len == 0 || optlen == 0 (programmer violates API)",
      ((len == 0) || (optlen == 0)), return ERR_ARG;);
  LWIP_ERROR("tcp_enqueue: arg == NULL || optdata == NULL (programmer violates 
API)",
      ((arg == NULL) || (optdata == NULL)), return ERR_ARG;);

[...checksums...]

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

Sure, but UDP performance is rarely critical, and it seems wasteful to
extend struct pbuf just for that.

Like you say, we could make inet_chksum_memcpy() part of the API, and
provide a udp_send_to_with_chksum API.

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

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

I agree. Besides, any attempt at a portable memcpy would be worse than
what the platform offers.

Ports could provide optimized versions, just like the standard checksum
function.

Regards,
/stoklund