| To: | Donald Becker <becker@xxxxxxxxx> |
|---|---|
| Subject: | Re: 3c59x 2.4.18 userspace seeing UDP packets with bad checksum? |
| From: | jamal <hadi@xxxxxxxxxx> |
| Date: | Wed, 31 Jul 2002 07:46:28 -0400 (EDT) |
| Cc: | <kuznet@xxxxxxxxxxxxx>, bert hubert <ahu@xxxxxxx>, <netdev@xxxxxxxxxxx>, <akpm@xxxxxxxxxx>, <jgarzik@xxxxxxxxxxxxxxxx> |
| In-reply-to: | <Pine.LNX.4.44.0207300947190.1266-100000@beohost.scyld.com> |
| Sender: | owner-netdev@xxxxxxxxxxx |
On Tue, 30 Jul 2002, Donald Becker wrote:
> int csum_bits = rx_status & 0xee000000;
> if (csum_bits &&
> (csum_bits == (IPChksumValid | TCPChksumValid) ||
> csum_bits == (IPChksumValid | UDPChksumValid))) {
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> Note that this relies on the kernel to make the final decision that the
> checksum is invalid.
>
> [[ This is the correct semantics: the driver might indicate that a protocol
> level checksum is correct, but it should not discard packets based
> on its (necessarily limited) understanding of higher level protocols.
> ]]
>
Nod.
So is CHECKSUM_WRONG needed to give a hint to the stack? It is possible
IPcsum is right but not the transport; Maybe ip_summed needs to be a
bitmap then?
You could use the information to move packets out of the stack fastpath
for example.
cheers,
jamal
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Help on firewall hooks, puja |
|---|---|
| Next by Date: | [ANNOUNCE] new lksctp release lksctp-2_5_29-0_5_0, Jon Grimm |
| Previous by Thread: | Re: 3c59x 2.4.18 userspace seeing UDP packets with bad checksum?, Donald Becker |
| Next by Thread: | Re: 2.4.18 userspace seeing UDP packets with bad checksum?, Andi Kleen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |