Hello Wensong,
> The size=40 is exactly the size of struct iphdr and tcphdr, so the size of
> payload is zero, so this is zero data packet, it seldom helps in real
> applications.
;)
> csum_partial implementations on other architectures is right. I used to
> provide a patch.
What exactly do you mean by 'used to provide'?
> --- linux/arch/i386/lib/checksum.S.orig Wed Sep 6 05:01:35 2000
> +++ linux/arch/i386/lib/checksum.S Fri Jul 13 09:54:37 2001
> @@ -149,6 +149,8 @@
> 30: subl $2, %ecx
> ja 20b
> je 32f
> + addl $2, %ecx
> + jz 80f
> movzbl (%esi),%ebx # csumming 1 byte, 2-aligned
> addl %ebx, %eax
> adcl $0, %eax
Ok, so I could also compile my kernel for 386/486 and I would be happy.
This seems to be code for Pentium PRO and up only, no?
> But the kernel guru insist that the caller should check the length first
> before csum_partial, their assumption on csum_partial calling is the
> length must be >0. Maybe I need to make a shell of ip_vs_csum_partial to
> correct this problem.
Holy cow, I see. So yes, why don't you make sort of a wrapper, just
like you did for skb_cow :)
Happy csum'ing,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |
dc
|