Re: TSO, SMP and the em driver.

On Friday 15 September 2006 06:45, Andre Oppermann wrote:
> Gleb Smirnoff wrote:
> > On Wed, Sep 13, 2006 at 10:46:22AM -0500, Brooks Davis wrote:
> > B> On Wed, Sep 13, 2006 at 11:08:44AM -0400, John Baldwin wrote:
> > B> > On Tuesday 12 September 2006 19:14, Andre Oppermann wrote:
> > B> > > Mike Tancsa wrote:
> > B> > > > At 12:43 PM 9/12/2006, Andre Oppermann wrote:
> > B> > > > 
> > B> > > >> TSO != (vlan && promisc)
> > B> > > > 
> > B> > > > Sorry, the commonality I was referring to was VLAN hardware tagging and 
> > B> > > > how it must be enabled for TSO, but that breaks other things.  See a few 
> > B> > > > messages ago
> > B> > > > 
> > B> > http://lists.freebsd.org/pipermail/freebsd-current/2006-September/065818.html 
> > B> > > 
> > B> > > I'm sure we can find a workaround for that.
> > B> > 
> > B> > Well, you could have the em(4) driver manually handle TSO in software, which 
> > B> > is what it does to workaround the VLAN tag problem.  (It does VLAN 
> > B> > encapsulation in the driver.)  While VLAN insertion may be trivial, 
> > B> > re-implementing TCP segmentation in the driver might be a good bit less 
> > B> > trivial to do.  There's not going to be a simple easy workaround for this 
> > B> > hardware bug. :(
> > B> 
> > B> I'm not sure it's worth worrying about with GbE hardware.  Just disable
> > B> TSO in promiscuous mode.  Where TSO is going to really matter is 10GbE.
> > B> No supporting TSO in some configurations with GbE doesn't seem like a
> > B> big deal to me.
> > 
> > Yes, makeing TSO and promisc mutually exclusive would be fine.
> 
> There is no point in disabling TSO in when the card is in promisc mode.
> Promisc mode only affects the receive path where TSO doesn't do a thing,
> it is only used on the send path.

The real fix is that the network stack including bpf(4) needs to be aware
of VLANs that aren't stored in the packet data (mtag, mbuf header,
wherever).  If you fixed bridging and bpf to recoginize VLAN IDs in metadata
and handle them then em(4) wouldn't need this hack.  Also, if my understanding
is correct, this hack is really needed for _any_ ethernet driver that supports
vlan tagging in hardware unless we fix the stack consumers.

-- 
John Baldwin