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

quoted

quoted

quoted

-----Original Message-----
From: netdev-owner@vger.kernel.org
[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?
=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