Re: TSO, SMP and the em driver.

John Baldwin wrote:
> 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.

OK, I'll give it a try to fix the stack.

-- 
Andre