Date: Wed, 1 Nov 2006 15:19:43 GMT From: Paolo Pisati <piso@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 108918 for review Message-ID: <200611011519.kA1FJh5p060181@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=108918 Change 108918 by piso@piso_newluxor on 2006/11/01 15:18:55 Fix a comment. Affected files ... .. //depot/projects/soc2005/libalias/sys/netinet/ip_fw2.c#27 edit Differences ... ==== //depot/projects/soc2005/libalias/sys/netinet/ip_fw2.c#27 (text+ko) ==== @@ -3471,55 +3471,49 @@ /* * XXX - Libalias checksum offload 'duct tape': * - * locally generated packets have only - * pseudo-header - * checksum calculated and libalias will - screw it[1], - * so mark them for later fix. - * Moreover there are cases when libalias - modify tcp - * packet data[2], mark it for later fix too. + * locally generated packets have only + * pseudo-header checksum calculated + * and libalias will screw it[1], so + * mark them for later fix. Moreover + * there are cases when libalias + * modify tcp packet data[2], mark it + * for later fix too. * - * [1] libalias was never meant to run in - kernel, so - * it doesn't have any knowledge about - checksum - * offloading, and it expects a packet with - a full - * internet checksum. Unfortunately, packets - * generated locally will have just the pseudo - * header calculated, and when libalias tries - to - * adjust the checksum it will actually screw - it. + * [1] libalias was never meant to run + * in kernel, so it doesn't have any + * knowledge about checksum + * offloading, and it expects a packet + * with a full internet + * checksum. Unfortunately, packets + * generated locally will have just the + * pseudo header calculated, and when + * libalias tries to adjust the + * checksum it will actually screw it. * - * [2] when libalias modify tcp's data content, - * full TCP checksum has to be recomputed: - * the problem is that libalias doesn't have - any - * idea about checksum offloading - * To workaround this, we do not do - checksumming - * in LibAlias, but only mark the packets in - th_x2 - * field. If we receive a marked packet, we - * calculate correct checksum for it aware of - * offloading. - * Why such a terrible hack instead of - * recalculating checksum for each packet? - * Because the previous checksum was not - checked! - * Recalculating checksums for EVERY packet - will - * hide ALL transmission errors. Yes, marked - packets - * still suffer from this problem. But, sigh, - natd(8) - * has this problem, too. + * [2] when libalias modify tcp's data + * content, full TCP checksum has to + * be recomputed: the problem is that + * libalias doesn't have any idea + * about checksum offloading To + * workaround this, we do not do + * checksumming in LibAlias, but only + * mark the packets in th_x2 field. If + * we receive a marked packet, we + * calculate correct checksum for it + * aware of offloading. Why such a + * terrible hack instead of + * recalculating checksum for each + * packet? Because the previous + * checksum was not checked! + * Recalculating checksums for EVERY + * packet will hide ALL transmission + * errors. Yes, marked packets still + * suffer from this problem. But, + * sigh, natd(8) has this problem, + * too. * - * TODO: - * -make libalias mbuf aware (so it can handle - * delayed checksum) + * TODO: -make libalias mbuf aware (so + * it can handle delayed checksum) */ if (mcl->m_pkthdr.rcvif == NULL &&
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611011519.kA1FJh5p060181>