Hi,
I use 2.2.16 kernel.
I found that there is a sk_buff structure in
"/usr/src/linux/include/linux/skbuff.c", and
there is a variable "unsigned in csum;" in
the sk_buff structure.
I want to know this checksum check what information.
Could you give me a hand, please?
-=-=-=-=-=-=-=-
In fact, I found 64byte and 1518byte UDP packet waste different
time to do masquerade(ip_fw_masquerade).
Many books say NAT just modify header fields, so it should no
different between small and big packet size.
I guess the different time due to csum_partial(h.raw, doff, sum)
in ip_fw_masquerade(). Right? Thanks a lot.
(But I can't find out source code of this function.)
Cheers,
Tom
On Mon, 9 Apr 2001, nctucis wrote:
> Hi,
>
> I use 2.2.16 kernel.
> I found that there is a sk_buff structure in
> "/usr/src/linux/include/linux/skbuff.c", and
> there is a variable "unsigned in csum;" in
> the sk_buff structure.
>
> I want to know this checksum check what information.
> Could you give me a hand, please?
>
> -=-=-=-=-=-=-=-
> In fact, I found 64byte and 1518byte UDP packet waste different
> time to do masquerade(ip_fw_masquerade).
> Many books say NAT just modify header fields, so it should no
> different between small and big packet size.
> I guess the different time due to csum_partial(h.raw, doff, sum)
> in ip_fw_masquerade(). Right? Thanks a lot.
> (But I can't find out source code of this function.)
>
> Cheers,
> Tom
TCP/IP packets contain a checksum. The checksum is defined by the
standards. Linux checksums the IP packets in two ways, the first
is obvious, the second is the 'csum_partial_copy_generic' in
../linux/arch/i386/lib/checksum.S.
NAT, because it modifies the IP packet, must also modify the
checksum. However, the checksum is in the IP header so your
'books' are correct. FYI, since the checksum is known, the
IP address is known, and the standard is known. It is not
necessary to re-checksum the entire packet to produce a new
checksum after modification of some of the checksummed data
(IP address).
I think Linux recalculates the entire checksum over again so
you may have discovered an area where an improvement in performance
could be obtained.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Thanks a lot.
Do you know the purpose of csum_partial( ) function?
I can't find out it source code.
I can't believe that I have discovered an area where an
improvement in performance. Maybe I loss some thing.
Cheers,
Tom
> On Mon, 9 Apr 2001, nctucis wrote:
>
> > Hi,
> >
> > I use 2.2.16 kernel.
> > I found that there is a sk_buff structure in
> > "/usr/src/linux/include/linux/skbuff.c", and
> > there is a variable "unsigned in csum;" in
> > the sk_buff structure.
> >
> > I want to know this checksum check what information.
> > Could you give me a hand, please?
> >
> > -=-=-=-=-=-=-=-
> > In fact, I found 64byte and 1518byte UDP packet waste different
> > time to do masquerade(ip_fw_masquerade).
> > Many books say NAT just modify header fields, so it should no
> > different between small and big packet size.
> > I guess the different time due to csum_partial(h.raw, doff, sum)
> > in ip_fw_masquerade(). Right? Thanks a lot.
> > (But I can't find out source code of this function.)
> >
> > Cheers,
> > Tom
>
> TCP/IP packets contain a checksum. The checksum is defined by the
> standards. Linux checksums the IP packets in two ways, the first
> is obvious, the second is the 'csum_partial_copy_generic' in
> ../linux/arch/i386/lib/checksum.S.
>
> NAT, because it modifies the IP packet, must also modify the
> checksum. However, the checksum is in the IP header so your
> 'books' are correct. FYI, since the checksum is known, the
> IP address is known, and the standard is known. It is not
> necessary to re-checksum the entire packet to produce a new
> checksum after modification of some of the checksummed data
> (IP address).
>
> I think Linux recalculates the entire checksum over again so
> you may have discovered an area where an improvement in performance
> could be obtained.
>
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, 9 Apr 2001, gis88530 wrote:
> Thanks a lot.
> Do you know the purpose of csum_partial( ) function?
> I can't find out it source code.
>
Sure. It does a partial checksum of various IP fragments when they
are being assembled. By starting with 0 as the input parameter,
and the entire length of the IP packet, you calculate the whole
checksum. It's output has to be shifted into a short, added to the
low word of the result, then inverted, to complete the TCP/IP
checksum.
It was believed that partial checksumming during various stages
of IP packet assembly would improve performance. It is possible
that performance would be improved if the checksum was done only once,
though, because there is a lot of overhead in setting up pointers and
counters prior to calculating the checksum. However, the kind of
"performance" we are talking about is probably nothing that would
actually improve network I/O. That is currently limited by the Ethernet
devices. However, some CPU cycles could be saved.
> I can't believe that I have discovered an area where an
> improvement in performance. Maybe I loss some thing.
>
> Cheers,
> Tom
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.