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.
Bye,

Mipam.