Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Sep 2003 16:47:22 -0400 (EDT)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        freebsd-net@freebsd.org
Subject:   TCP Segmentation Offload
Message-ID:  <16216.63066.954104.582195@grasshopper.cs.duke.edu>

next in thread | raw e-mail | index | archive | help

I've been reading a little about TCP Segmentation Offload (aka TSO).
We don't appear to support it, but at least 2 of our supported nics
(e1000 and bge) apparently could support it.

The gist is that TCP pretends the nic has a large mtu, and passes a
large (> the mtu on the link layer) packet down to driver and then the
nic.  The nic then fragments the large packet into smaller (<=mtu)
packets.  It uses the initial TCP header as a template to construct
the headers for the "fragments.".  The people who implemented it on
linux claim a 50% CPU savings for an Intel 1Gb/s adaptor with a 1500
byte mtu. 

It seems like it could be implemented rather easily by adding an
if_hwassist flag (CSUM_TSO).  If this flag is set on the interface
found by tcp_mss(), then the mss is set to 56k.  This causes TCP to
generate huge packets.  We then add a check in ip_output() after the
(near the existing CSUM_FRAGMENT check) which checks to see if its
both a TCP packet, and if CSUM_TSO is set in the if_hwassist flags.
If so, the huge packet is passed on down to the driver.  Does this
sound reasonable?  The only other thing I can think of is that some
nics might not be able to handle such a large mss, and we might want
to stuff the maximum mss value into the ifnet struct.

I don't have a bge or an e1000, so I'm not ready to actually implement
this.   I'm  more considering firmware optimizations for our product,
and would implement it in a few months, after making the firmware
changes.

Drew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16216.63066.954104.582195>