Subject: Re: Intel i82547 performance problems in wm(4)
To: Matthias Scheler <firstname.lastname@example.org>
From: Mipam <email@example.com>
Date: 07/16/2004 12:59:20
On Fri, 16 Jul 2004, Matthias Scheler wrote:
> On Fri, Jul 16, 2004 at 12:14:58PM +0200, Mipam wrote:
> > > Why not? The card will calculate the correct checksum whether the firewall
> > > manipulated the packet or not. The firewall only has to cope with the
> > > fact that it will see outgoing packets with incorrect checksums.
> > But shouldnt tcp packets with incorrect tcp checksums be discarded
> > according rfc 793, causing a firewall to drop such a packet?
> 1.) When the packets hits the wire the checksum will be correct.
Yup, but i was thinking about outbound traffic.
> 2.) Packets with incorrect checksums on the send queue have a marked
> in the data structure so that the firewall software can recognize
> them and neither perform an initial checksum check nor bother to
> correct the checksum after changing the packet.
Ahh, okay, that clears the question on outbound traffic. :-)
> > And as for the benefits of offloading engines, on local networks with
> > several cards which support offloading it can make a difference (large
> > frames (if the switch supports them :-)), less interrupts) and so large
> > tcp windows can make a difference.
> Offload support in NetBSD doesn't affect TCP window handling. You are
> probably refering to LSO (large segment offload) which NetBSD doesn't
> support yet. NetBSD supports offloading IP, TCP and UDP checksums
> to the card. And that simply saves CPU cycles on the local machine.
> While the amount of saved CPU cycles per time interval of course
> depends on the utilized bandwidth it works for LAN and WAN connections.
> > On the internet jumbo frames dont work, ....
> Jump frames are a different concept than checksum offloading.
Okay, then i clearly confuse large mtu's with LSO.