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

-----Original Message-----
From: <redacted>
[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

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=

On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:

quoted

quoted

-----Original Message-----
From: <redacted>
[mailto:netdev-owner@vger.kernel.org] On Behalf Of Joakim Tjernlund

Sent: Tuesday, March 18, 2008 11:11 PM

quoted

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 <redacted>
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 <redacted>
---
 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

-----Original Message-----
From: Joakim Tjernlund [mailto:<redacted>]=20
Sent: Tuesday, March 25, 2008 5:18 PM
To: Li Yang
Cc: Netdev; <redacted>
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:

quoted

quoted

quoted

-----Original Message-----
From: <redacted>
[mailto:netdev-owner@vger.kernel.org] On Behalf Of=20

Joakim Tjernlund

quoted

quoted

Sent: Tuesday, March 18, 2008 11:11 PM

quoted

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

quoted

quoted

quoted

Also add 4 extra bytes for future expansion.

=20
IMO, VLAN and Jumbo packet support is not general case of=20

Ethernet.

quoted

quoted

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

quoted

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

quoted

soft VLAN is silently broken. Do you really want the user=20

to find and=20

quoted

turn on a controller specific feature to use VLAN?

13 more quoted lines

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

On Wed, 2008-03-26 at 20:43 +0800, Li Yang wrote:

quoted

-----Original Message-----
From: Joakim Tjernlund [mailto:<redacted>] 
Sent: Tuesday, March 25, 2008 5:18 PM
To: Li Yang
Cc: Netdev; <redacted>
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:

quoted

quoted

quoted

-----Original Message-----
From: <redacted>
[mailto:netdev-owner@vger.kernel.org] On Behalf Of 

Joakim Tjernlund

quoted

quoted

Sent: Tuesday, March 18, 2008 11:11 PM

quoted

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. 

quoted

quoted

quoted

Also add 4 extra bytes for future expansion.

IMO, VLAN and Jumbo packet support is not general case of 

Ethernet.

quoted

quoted

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 

quoted

would inject an extra 4 bytes into the frame.
This change does not change the visible MTU for the user. 

As is now, 

quoted

soft VLAN is silently broken. Do you really want the user 

to find and 

quoted

turn on a controller specific feature to use VLAN?

35 more quoted lines

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

quoted

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

quoted

ug_info instead of increasing the MaxLength for both tagged=20

and untagged frames.

quoted

See the following part from the reference manual.
=20
The MFLR entry in the Global Parameter RAM defines the=20

length of the=20

quoted

largest frame, excluding Q TAG but including FCS, that is=20

still valid.=20

quoted

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

quoted

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