Message-ID: <20101215081606.18e12fc9@xenia.leun.net>
Date:	Wed, 15 Dec 2010 08:16:06 +0100
From:	Michael Leun <lkml20101129@...ton.leun.net>
To:	"Matt Carlson" <mcarlson@...adcom.com>
Cc:	"Jesse Gross" <jesse@...ira.com>,
	"Michael Chan" <mchan@...adcom.com>,
	"Eric Dumazet" <eric.dumazet@...il.com>,
	"David Miller" <davem@...emloft.net>,
	"Ben Greear" <greearb@...delatech.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not
 used

On Tue, 14 Dec 2010 17:34:31 -0800
"Matt Carlson" <mcarlson@...adcom.com> wrote:

> On Tue, Dec 14, 2010 at 04:24:30PM -0800, Michael Leun wrote:
> > On Tue, 14 Dec 2010 11:15:00 -0800
> > "Matt Carlson" <mcarlson@...adcom.com> wrote:
> > > Michael, I'm wondering if the difference in behavior can be
> > > explained by the presence or absence of management firmware.  Can
> > > you look at the driver sign-on messages in your syslogs for
> > > ASF[]?  I'm half expecting the 5752 to show "ASF[0]" and the 5714
> > > to show "ASF[1]". If you see this, and the below patch doesn't
> > > fix the problem, let me know.  I have another test I'd like you
> > > to run.
> > 
> > Do I understand this correct? "Management firmware" or ASF is some
> > feature, vendor decides to built into network card (firmware) or
> > not?
> 
> Right.
> 
> > If so, would'nt one expect two oneboard network cards in one server
> > to look alike?
> 
> Mostly, yes.  Except for.....
> 
> > HP Proliant DL320G5
> > 
> > <6>tg3.c:v3.113 (August 2, 2010)
> > <6>tg3 0000:03:04.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> > <6>tg3 0000:03:04.0: eth0: Tigon3 [partno(N/A) rev 9003]
> > (PCIX:133MHz:64-bit) MAC address xx:xx:xx:xx:xx:xx <6>tg3
> > 0000:03:04.0: eth0: attached PHY is 5714 (10/100/1000Base-T
> > Ethernet) (WireSpeed[1]) <6>tg3 0000:03:04.0: eth0: RXcsums[1]
> > LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
>                                                       This =>  ^^^^^^
> > <6>tg3 0000:03:04.0: eth0: dma_rwctrl[76148000] dma_mask[64-bit]
> > <6>tg3 0000:03:04.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> > <6>tg3 0000:03:04.1: eth1: Tigon3 [partno(N/A) rev 9003]
> > (PCIX:133MHz:64-bit) MAC address xx:xx:xx:xx:xx:xx <6>tg3
> > 0000:03:04.1: eth1: attached PHY is 5714 (10/100/1000Base-T
> > Ethernet) (WireSpeed[1]) <6>tg3 0000:03:04.1: eth1: RXcsums[1]
> > LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
>                                                   And this =>  ^^^^^^
> > <6>tg3 0000:03:04.1: eth1: dma_rwctrl[76148000] dma_mask[64-bit]
> 
> So management firmware is turned off on the second port.
> 
> > Lenovo ThinkPad z61m
> > 
> > [    2.679130] tg3.c:v3.113 (August 2, 2010)
> > [    2.679176] tg3 0000:02:00.0: PCI INT A -> GSI 16 (level, low)
> > -> IRQ 16 [    2.679188] tg3 0000:02:00.0: setting latency timer to
> > 64 [    2.728572] tg3 0000:02:00.0: eth0: Tigon3 [partno(BCM95752m)
> > rev 6002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > [    2.728577] tg3 0000:02:00.0: eth0: attached PHY is 5752
> > (10/100/1000Base-T Ethernet) (WireSpeed[1]) [    2.728581] tg3
> > 0000:02:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
> > TSOcap[1]
>                                                                            ^^^^^^
> And it isn't present on the 5752.
> 
> > [    2.728585] tg3 0000:02:00.0: eth0: dma_rwctrl[76180000]
> > dma_mask[64-bit]
> > 
> > 
> > > ----
> > > 
> > > [PATCH] tg3: Use new VLAN code
> > 
> > Unfortunately had'nt time to try much now, but with 2.6.37-rc5 /
> > your patch on the DL320, single user mode (nothing configured on
> > eth) just after ifconfig eth0/eth1 up I see NO vlan tags on eth0
> > but I see vlan tags on eth1, so there clearly is a difference.
> > 
> > I should have checked if I still see vlan tags on eth1 if I
> > configure some vlan there - if helpful maybe I can do this (have to
> > look, when I can effort another downtime).
> 
> This would be helpful, just to solidify our findings.
> 
> > I wonder, if the difference in that both onboard cards is really
> > there or if there is some malfunction in detecion?
> 
> Please run the above test first, but afterwards, can you apply the
> below patch on top of your current sources.  I suspect eth1 will
> begin to act like eth0.
> 
> This patch is just a test.
> 
> [PATCH] tg3: Always strip VLAN tags
> 
> This patch configures the hardware to always strip VLAN tags from
> incoming packets.

OK - all tests done on that DL320G5:

For completeness, 2.6.37-rc5 unpatched:

eth0, no vlan configured: totally broken - see double tagged vlans
without tag, single or untagged packets missing at all

eth0, vlan configured: see packets without vlan tag (see double tagged
packets with one vlan tag)

eth1 same as originally reported:
without vlan configured see vlan tags (single and double tagged as
expected)
with vlan configured: see packets without vlan tag (see double tagged
packets with one vlan tag)


2.6.37-rc5, your tg3 use new vlan-code patch:

eth0, no vlan configured:  see packets without vlan tag (see double
tagged packets with one vlan tag)
eth1, no vlan configured: see vlan tags (single and double tagged as
expected)


eth0, vlan configured: as without vlan
eth1, vlan configured: as without vlan

2.6.37-rc5, your tg3 use new vlan-code patch with test patch ontop

eth1 no vlan configured: see packets without vlan tag (see double tagged
packets with one vlan tag)
eth1 with vlan: the same

Hope I did not miss a test I should have done - hope, I did not confuse
anything. If something is not what you would expect you might ask, I've
a script from that session and can look (but cannot post that, sorry).




-- 
MfG,

Michael Leun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists