[Top][All Lists]

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

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

From: Simon Goldschmidt
Subject: [lwip-devel] [patch #6253] Added csum to struct pbuf.
Date: Thu, 01 Nov 2007 13:11:45 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20071008 Firefox/

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,

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

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


  Nachricht geschickt von/durch Savannah

reply via email to

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