RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Li Yang]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org=20
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Joakim Tjernlund
> Sent: Tuesday, March 18, 2008 11:11 PM
> To: Netdev; Li Yang
> Cc: Joakim Tjernlund
> Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
>=20
> Creating a VLAN interface on top of ucc_geth adds 4 bytes to=20
> the frame and the HW controller is not prepared to TX a frame=20
> bigger than 1518 bytes which is 4 bytes too small for a full=20
> VLAN frame. Also add 4 extra bytes for future expansion.

IMO, VLAN and Jumbo packet support is not general case of Ethernet.
Could you make this change optional?  Thanks.

- Leo

>=20
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
>  drivers/net/ucc_geth.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>=20
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c=20
> index 348892b..038ec75 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -114,10 +114,10 @@ static struct ucc_geth_info=20
> ugeth_primary_info =3D {
>  	.maxGroupAddrInHash =3D 4,
>  	.maxIndAddrInHash =3D 4,
>  	.prel =3D 7,
> -	.maxFrameLength =3D 1518,
> +	.maxFrameLength =3D 1518+8, /* Add 4 bytes for VLAN tags=20
> and 4 extra=20
> +bytes */
>  	.minFrameLength =3D 64,
> -	.maxD1Length =3D 1520,
> -	.maxD2Length =3D 1520,
> +	.maxD1Length =3D 1520+8,
> +	.maxD2Length =3D 1520+8,
>  	.vlantype =3D 0x8100,
>  	.ecamptr =3D ((uint32_t) NULL),
>  	.eventRegMask =3D UCCE_OTHER,
> --
> 1.5.4.3
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe=20
> netdev" in the body of a message to majordomo@vger.kernel.org=20
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>=20

Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Joakim Tjernlund]

Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG5ldGRldi1vd25lckB2Z2Vy
Lmtlcm5lbC5vcmcNCj4+IFttYWlsdG86bmV0ZGV2LW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24g
QmVoYWxmIE9mIEpvYWtpbSBUamVybmx1bmQNCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTgsIDIw
MDggMTE6MTEgUE0NCj4+IFRvOiBOZXRkZXY7IExpIFlhbmcNCj4+IENjOiBKb2FraW0gVGplcm5s
dW5kDQo+PlN1YmplY3Q6IFtQQVRDSF0gdWNjX2dldGg6IEFkZCA4IGJ5dGVzIHRvIG1heCBUWCBm
cmFtZSBmb3IgVkxBTnMNCj4+DQo+PiBDcmVhdGluZyBhIFZMQU4gaW50ZXJmYWNlIG9uIHRvcCBv
ZiB1Y2NfZ2V0aCBhZGRzIDQgYnl0ZXMgdG8NCj4+IHRoZSBmcmFtZSBhbmQgdGhlIEhXIGNvbnRy
b2xsZXIgaXMgbm90IHByZXBhcmVkIHRvIFRYIGEgZnJhbWUNCj4+IGJpZ2dlciB0aGFuIDE1MTgg
Ynl0ZXMgd2hpY2ggaXMgNCBieXRlcyB0b28gc21hbGwgZm9yIGEgZnVsbA0KPj4gVkxBTiBmcmFt
ZS4gQWxzbyBhZGQgNCBleHRyYSBieXRlcyBmb3IgZnV0dXJlIGV4cGFuc2lvbi4NCj4gDQo+IElN
TywgVkxBTiBhbmQgSnVtYm8gcGFja2V0IHN1cHBvcnQgaXMgbm90IGdlbmVyYWwgY2FzZSBvZiBF
dGhlcm5ldC4NCj4gQ291bGQgeW91IG1ha2UgdGhpcyBjaGFuZ2Ugb3B0aW9uYWw/ICBUaGFua3Mu
DQo+IA0KPiAtIExlbyANCg0KaG1tLCBJIGRvIG5vdCBhZ3JlZS4gVkxBTiBpcyBjb21tb24gdG9k
YXkuDQoNCklmIHlvdSB3ZXJlIHRvIGVuYWJsZSBIVyBzdXBwb3J0IGZvciBWTEFOIHRoZW4gdGhl
IGV0aGVybmV0IGNvbnRyb2xsZXIgd291bGQgaW5qZWN0IGFuIGV4dHJhIDQgYnl0ZXMgaW50byB0
aGUgZnJhbWUuIA0KVGhpcyBjaGFuZ2UgZG9lcyBub3QgY2hhbmdlIHRoZSB2aXNpYmxlIE1UVSBm
b3IgdGhlIHVzZXIuIEFzIGlzIG5vdywgc29mdCBWTEFOIGlzIHNpbGVudGx5IGJyb2tlbi4gRG8g
eW91DQpyZWFsbHkgd2FudCB0aGUgdXNlciB0byBmaW5kIGFuZCB0dXJuIG9uIGEgY29udHJvbGxl
ciBzcGVjaWZpYyBmZWF0dXJlIHRvIHVzZSBWTEFOPw0KDQpXaGF0IGRvZXMgbmV0ZGV2IHBlb3Bs
ZSB0aGluaz8gDQoNCiBKb2NrZSANCg0KDQo=

Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Joakim Tjernlund]

On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org
> >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Joakim Tjernlund
> > Sent: Tuesday, March 18, 2008 11:11 PM
> >> To: Netdev; Li Yang
> >> Cc: Joakim Tjernlund
> >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> >>
> >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to
> >> the frame and the HW controller is not prepared to TX a frame
> >> bigger than 1518 bytes which is 4 bytes too small for a full
> >> VLAN frame. Also add 4 extra bytes for future expansion.
> > 
> > IMO, VLAN and Jumbo packet support is not general case of Ethernet.
> > Could you make this change optional?  Thanks.
> > 
> > - Leo
> 
> hmm, I do not agree. VLAN is common today.
> 
> If you were to enable HW support for VLAN then the ethernet controller
> would inject an extra 4 bytes into the frame. 
> This change does not change the visible MTU for the user. As is now,
> soft VLAN is silently broken. Do you
> really want the user to find and turn on a controller specific feature
> to use VLAN?
> 
> What does netdev people think? 
> 
>  Jocke 

hmm, I misread the HW specs. The change has nothing to do with TX, it is
the MAX RX frame size that was too small for VLAN and that is what the
patch addresses. I see that tg3.c adds 4 bytes to MAX RX pkgs:
 	/* MTU + ethernet header + FCS + optional VLAN tag */
	tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8);
So I don't think this change should be hidden behind a new CONFIG
option. Updated patch below with changed description.

 Jocke

>From ec8ca3c9666bdc72652e403ea5f252b38e5a076b Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 18 Mar 2008 15:40:59 +0100
Subject: [PATCH] ucc_geth: Add 8 bytes to max RX frame for VLANs

Creating a VLAN interface on top of ucc_geth adds 4 bytes
to the frame and the HW controller is not prepared to
receive a frame bigger than 1518 bytes which is 4 bytes too
small for a full VLAN frame. Also add 4 extra bytes for future
expansion.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 drivers/net/ucc_geth.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 348892b..038ec75 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -114,10 +114,10 @@ static struct ucc_geth_info ugeth_primary_info = {
 	.maxGroupAddrInHash = 4,
 	.maxIndAddrInHash = 4,
 	.prel = 7,
-	.maxFrameLength = 1518,
+	.maxFrameLength = 1518+8, /* Add 4 bytes for VLAN tags and 4 extra bytes */
 	.minFrameLength = 64,
-	.maxD1Length = 1520,
-	.maxD2Length = 1520,
+	.maxD1Length = 1520+8,
+	.maxD2Length = 1520+8,
 	.vlantype = 0x8100,
 	.ecamptr = ((uint32_t) NULL),
 	.eventRegMask = UCCE_OTHER,
-- 
1.5.4.3

RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Li Yang]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20
> Sent: Tuesday, March 25, 2008 5:18 PM
> To: Li Yang
> Cc: Netdev; Linuxppc-Embedded@Ozlabs.Org
> Subject: Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
>=20
>=20
> On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> > >> -----Original Message-----
> > >> From: netdev-owner@vger.kernel.org
> > >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of=20
> Joakim Tjernlund
> > > Sent: Tuesday, March 18, 2008 11:11 PM
> > >> To: Netdev; Li Yang
> > >> Cc: Joakim Tjernlund
> > >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > >>
> > >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to the=20
> > >> frame and the HW controller is not prepared to TX a frame bigger=20
> > >> than 1518 bytes which is 4 bytes too small for a full=20
> VLAN frame.=20
> > >> Also add 4 extra bytes for future expansion.
> > >=20
> > > IMO, VLAN and Jumbo packet support is not general case of=20
> Ethernet.
> > > Could you make this change optional?  Thanks.
> > >=20
> > > - Leo
> >=20
> > hmm, I do not agree. VLAN is common today.
> >=20
> > If you were to enable HW support for VLAN then the ethernet=20
> controller=20
> > would inject an extra 4 bytes into the frame.
> > This change does not change the visible MTU for the user.=20
> As is now,=20
> > soft VLAN is silently broken. Do you really want the user=20
> to find and=20
> > turn on a controller specific feature to use VLAN?
> >=20
> > What does netdev people think?=20
> >=20
> >  Jocke
>=20
> hmm, I misread the HW specs. The change has nothing to do=20
> with TX, it is the MAX RX frame size that was too small for=20
> VLAN and that is what the patch addresses. I see that tg3.c=20
> adds 4 bytes to MAX RX pkgs:
>  	/* MTU + ethernet header + FCS + optional VLAN tag */
> 	tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8); So=20
> I don't think this change should be hidden behind a new=20
> CONFIG option. Updated patch below with changed description.

Hi Jocke,

QUICC engine supports dynamic maximum frame length.  If you are not
expecting to receive only tagged frames, I recommend to use this feature
by setting dynamicMaxFrameLength and dynamicMinFrameLength in ug_info
instead of increasing the MaxLength for both tagged and untagged frames.
See the following part from the reference manual.

The MFLR entry in the Global Parameter RAM defines the length of the
largest frame, excluding Q TAG
but including FCS, that is still valid. When REMODER[DXE]=3D1, a tagged
frame that has length equals
MaxLength+4 considered valid, and a non tagged frame that has length
equals MaxLength is the longest
that is still considered valid. When REMODER[DXE]=3D0, any frame longer
than MaxLength consider
erroneous frame.
For systems with only tagged frames, set REMODER[DXE]=3D0 and set
MaxLength =3D Max LLC size+4.

- Leo

RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Joakim Tjernlund]

On Wed, 2008-03-26 at 20:43 +0800, Li Yang wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se] 
> > Sent: Tuesday, March 25, 2008 5:18 PM
> > To: Li Yang
> > Cc: Netdev; Linuxppc-Embedded@Ozlabs.Org
> > Subject: Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > 
> > 
> > On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> > > >> -----Original Message-----
> > > >> From: netdev-owner@vger.kernel.org
> > > >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of 
> > Joakim Tjernlund
> > > > Sent: Tuesday, March 18, 2008 11:11 PM
> > > >> To: Netdev; Li Yang
> > > >> Cc: Joakim Tjernlund
> > > >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > > >>
> > > >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to the 
> > > >> frame and the HW controller is not prepared to TX a frame bigger 
> > > >> than 1518 bytes which is 4 bytes too small for a full 
> > VLAN frame. 
> > > >> Also add 4 extra bytes for future expansion.
> > > > 
> > > > IMO, VLAN and Jumbo packet support is not general case of 
> > Ethernet.
> > > > Could you make this change optional?  Thanks.
> > > > 
> > > > - Leo
> > > 
> > > hmm, I do not agree. VLAN is common today.
> > > 
> > > If you were to enable HW support for VLAN then the ethernet 
> > controller 
> > > would inject an extra 4 bytes into the frame.
> > > This change does not change the visible MTU for the user. 
> > As is now, 
> > > soft VLAN is silently broken. Do you really want the user 
> > to find and 
> > > turn on a controller specific feature to use VLAN?
> > > 
> > > What does netdev people think? 
> > > 
> > >  Jocke
> > 
> > hmm, I misread the HW specs. The change has nothing to do 
> > with TX, it is the MAX RX frame size that was too small for 
> > VLAN and that is what the patch addresses. I see that tg3.c 
> > adds 4 bytes to MAX RX pkgs:
> >  	/* MTU + ethernet header + FCS + optional VLAN tag */
> > 	tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8); So 
> > I don't think this change should be hidden behind a new 
> > CONFIG option. Updated patch below with changed description.
> 
> Hi Jocke,
> 
> QUICC engine supports dynamic maximum frame length.  If you are not
> expecting to receive only tagged frames, I recommend to use this feature
> by setting dynamicMaxFrameLength and dynamicMinFrameLength in ug_info
> instead of increasing the MaxLength for both tagged and untagged frames.
> See the following part from the reference manual.
> 
> The MFLR entry in the Global Parameter RAM defines the length of the
> largest frame, excluding Q TAG
> but including FCS, that is still valid. When REMODER[DXE]=1, a tagged
> frame that has length equals
> MaxLength+4 considered valid, and a non tagged frame that has length
> equals MaxLength is the longest
> that is still considered valid. When REMODER[DXE]=0, any frame longer
> than MaxLength consider
> erroneous frame.
> For systems with only tagged frames, set REMODER[DXE]=0 and set
> MaxLength = Max LLC size+4.
> 
> - Leo

Interesting, that should also work although QinQ will not. I will have
a closer look but I still don't see how my orginal patch would
harm anything. One could add my patch on top but with only 4 bytes
extra.

 Jocke

RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

[Li Yang]

> > Hi Jocke,
> >=20
> > QUICC engine supports dynamic maximum frame length.  If you are not=20
> > expecting to receive only tagged frames, I recommend to use this=20
> > feature by setting dynamicMaxFrameLength and=20
> dynamicMinFrameLength in=20
> > ug_info instead of increasing the MaxLength for both tagged=20
> and untagged frames.
> > See the following part from the reference manual.
> >=20
> > The MFLR entry in the Global Parameter RAM defines the=20
> length of the=20
> > largest frame, excluding Q TAG but including FCS, that is=20
> still valid.=20
> > When REMODER[DXE]=3D1, a tagged frame that has length equals
> > MaxLength+4 considered valid, and a non tagged frame that has length
> > equals MaxLength is the longest
> > that is still considered valid. When REMODER[DXE]=3D0, any=20
> frame longer=20
> > than MaxLength consider erroneous frame.
> > For systems with only tagged frames, set REMODER[DXE]=3D0 and set=20
> > MaxLength =3D Max LLC size+4.
> >=20
> > - Leo
>=20
> Interesting, that should also work although QinQ will not. I=20
> will have a closer look but I still don't see how my orginal=20
> patch would harm anything. One could add my patch on top but=20
> with only 4 bytes extra.

Hi,

The increase of max packet length may cause a waste of QE internal
buffer for every packet.  Furthermore it affects the hardware statistics
of jumbo packets.

- Leo