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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 28 Mar 2008 10:54:16 +0800
From:	"Li Yang" <LeoLi@...escale.com>
To:	<joakim.tjernlund@...nsmode.se>
Cc:	"Netdev" <netdev@...r.kernel.org>,
	"Linuxppc-Embedded@...abs.Org" <linuxppc-embedded@...abs.org>
Subject: RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs

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

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html