lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [patch #6253] Added csum to struct pbuf.


From: Andrey Volkov
Subject: [lwip-devel] [patch #6253] Added csum to struct pbuf.
Date: Thu, 01 Nov 2007 15:28:54 +0000
User-agent: Opera/9.00 (Windows NT 5.1; U; ru)

Follow-up Comment #11, patch #6253 (project lwip):

Simon Goldschmidt wrote:
> Follow-up Comment #6, patch #6253 (project lwip):
> 
> Andrey Volkov wrote:
>> Yes, but I introduce this field mainly for next purposes:
>>  1) speed up reassembly of incoming ip packets. In reassembly case,
>>     ip payload csum of each fragment should be stored somewhere.
>>     (IMHO, pbuf is very appropriate for it).
> 
> That might be solved best by a change of the IP implementation by not
> checking reassembled packets again (we check a checksum we generate
ourselves,
> anyway...)
> 
>>  2) Hardware usually could calculate ip payload/headers checksum,
>>     but not tcp/udp pseudo checksum, hence ip csum should be stored.
>>     Also, I dislike to mix different levels of stack in one piece
>>     of code. I.e. if I've ip checksum in eth driver, I could undef
>>     CHECKSUM_CHECK_IP, but not CHECKSUM_CHECK_TCP/CHECKSUM_CHECK_UDP,
>>     since I don't know it in driver level.
> 
> I don't think I really understand you here. Could you maybe describe your
> changes to inet_chksum_pseudo_partial()? What I understand from reading
the
> code, you use p->csum for the last pbuf in a linked list only, so
effectively
> per packet, not per pbuf! (But then again, if your pbufs are big enough to
> hold a full packet - no pbuf chains - then this is the same for you.)
Yes, it is misunderstandings from your side ;).

Well I'll try to describe how I currently use lwip:

1) BF537 have _chained_ DMA (i.e. could send/receive N chained pbufs)
   and could calculate ip payload/headers csum only for a single 
   _incoming_ eth packet.
2) In my app. I need to transfer large udp packets (i.e. they fragmented
   almost always).
3) When I fill payload for outgoing udp d-gramms, I calculate csum for 
   it _before_ I call udp_send (and do it fast in asm).
   So only what lwip is need to do, is calculate csum for udp/ip 
   headers. I.e. on input of inet_chksum_pseudo in udp_send 
   I've chain minimum from 2 pbufs:
   udp header (without valid csum) and ref to my large udp payload
  (with valid csum).
4) When stack receive fragmented udp, ip csum, calculated by hwd.,
   presented not in every ip fragment (mainly pbuf's csum must be 
   recalculated if pbuf_realloc in ip_input really truncate pbuf).
   So, when inet_chksum_pseudo called from udp_input for reassembled 
   udp, it have again pbuf's chain with partially calculated csum as 
   input arg :(.

In both cases I need csum field in _every_ pbuf, and I'm ready to 
sacrifice memory space for any other pbuf usage.

Now about inet_chksum_pseudo: it check flag in _every_ pbuf of chain,
and if it set then use value of csum field, if not then calculate it.
If, in simplest case, chain contain only one pbuf with valid csum, then 
inet_chksum_pseudo should do nothing. Same for inet_chksum_pseudo_partial
(checksum_len, in general case, could be greater then size of one pbuf).

> 
>> And,
>>  3) In my hwd. driver, I don't 'memcpy' incoming packets, DMA do it
>>     directly to pbuf.
> 
> Of course, that's because task #6849 wants to speed up systems that don't
> have HW-checksum engines (by only loading the data once into the processor
by
> combining memcpy with checksum generation).



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?6253>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

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