> -----Original Message----- > From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] 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 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
