Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote: Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. Have you tried ``sysctl net.inet.ip.fastforwarding=1''? It's documented in the inet(4) manpage. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote: Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? It is done this way because the standards demand that it be done this way. RFC1812 says, 4.2.2.5 Header Checksum: RFC 791 Section 3.1 As stated in Section [5.2.2], a router MUST verify the IP checksum of any packet that is received, and MUST discard messages containing invalid checksums. The router MUST NOT provide a means to disable this checksum verification. Keeping a single host from polluting the whole network, and only its LAN, with bad packets is considered worth the cost of every router doing the check. FWIW, this is one of the few places a standard demands that you not even provide the option to disable a feature. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_input - chksum - why is it done so early in ip_input?
Sten Daniel Sørsdal wrote: Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. Only the IP header checksum is checked. We don't want to forward a packet with a broken header because we can't be sure if it wasn't the destination address that is broken. Be aware that we do not calculate any checksum of the entire IP packet. (This is up to the higher level protocol). It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? On modern networks card (mostly GigE) you have hardware support for that. So there is no expense anymore. I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Can you qualify this more? The checksumming touches only 20 bytes (or a couple more if ip options are present). Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. We are working on it to make it even faster. If you are using 5.2 or -current you get the first step of it by enabling net.inet.ip.fastfowarding. This is a newly written fast path for packet forwarding. (Do not do this on 4.9 because that is the old ip_flow code). -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, 17 Jan 2004, Andre Oppermann wrote: Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. We are working on it to make it even faster. If you are using 5.2 or -current you get the first step of it by enabling net.inet.ip.fastfowarding. This is a newly written fast path for packet forwarding. (Do not do this on 4.9 because that is the old ip_flow code). You can also enable debug.mpsafenet, which disables holding the Giant lock over the forwarding path for supported ethernet drivers. Unfortunately, this option can't be used with KAME IPSEC or IPv6 yet, but can be used with FAST_IPSEC. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ip_input - chksum - why is it done so early in ip_input?
Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. _// Sten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
