Date: Thu, 7 Dec 2006 16:14:06 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Perforce Change Reviews <perforce@FreeBSD.org>, Andre Oppermann <andre@FreeBSD.org>, Paolo Pisati <piso@FreeBSD.org> Subject: Re: PERFORCE change 111230 for review Message-ID: <20061207160859.V50906@fledge.watson.org> In-Reply-To: <20061207124112.GW32700@FreeBSD.org> References: <200612062319.kB6NJgsq031755@repoman.freebsd.org> <20061207110225.GU32700@FreeBSD.org> <4578070A.2030609@freebsd.org> <20061207124112.GW32700@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Dec 2006, Gleb Smirnoff wrote: > A> >this isn't a fix. Another application will do write(,, 16k + 1) and > A> >m_jumbo16pullup() will fail again. Please backout it, it is a hack. > A> > > A> >We need to fix TSO in such way that real packets, that will be > A> >transmitted to wire, will be passed to pfil handlers. > A> > A> That is not possible. > > ATM this should be at least documented behavior. And a solution should be > thought, because pfil must see real packets, not their precursors. This tension will always exist with offloaded services. tcpdump sees "corrupted" checksums on transmitted packets, and now it sees "long" TCP packets. Likewise, with reassembly offload, they'll come from the card in a reassembled form (this is present in the Neterion cards, which can do fragment reassembly, etc, in hardware, and pass a large datagram up the stack). I don't see any way of getting around the fact that IP processing happens before or after the firewall in the New World Order. If a firewall really wants to see the packets as they will be transmitted, it can always do the fragmentation and checksumming itself. However, this is pretty undesirable from a performance perspective. I think pfil seeing the cards as they transit the IP layer is the right approach. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061207160859.V50906>