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

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

[Andy Fleming]

From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>

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.

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 8f944e5..8fed4bb 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -113,10 +113,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.GIT

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

[Jeff Garzik]

Andy Fleming wrote:
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> 
> 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.
> 
> 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 8f944e5..8fed4bb 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -113,10 +113,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,

Is this still needed?

I found this buried in my inbox.

If so, please resend with the "+8" converted into a named constant. 
Hardcoding lengths like this without named constants (or comments, on 
the other lines) tends to be an error-prone practice.

	Jeff

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

[Joakim Tjernlund]

On Sun, 2008-11-02 at 08:18 -0500, Jeff Garzik wrote:
> Andy Fleming wrote:
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > 
> > 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.
> > 
> > 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 8f944e5..8fed4bb 100644
> > --- a/drivers/net/ucc_geth.c
> > +++ b/drivers/net/ucc_geth.c
> > @@ -113,10 +113,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,
> 
> Is this still needed?
> 
> I found this buried in my inbox.
> 
> If so, please resend with the "+8" converted into a named constant. 
> Hardcoding lengths like this without named constants (or comments, on 
> the other lines) tends to be an error-prone practice.

Yes, it is. I do recall the maintainer had some comments though.
Secondly, I think it should be changed to 8 extra bytes so
you can fit VLAN+pppoe=4+8 bytes. Possibly it could
be configuarble at complile time.

Andy, you think you can work out the details with the maintainer?
I am much to busy ATM.

 Jocke

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

[Andy Fleming]

On Fri, Nov 7, 2008 at 4:18 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> On Sun, 2008-11-02 at 08:18 -0500, Jeff Garzik wrote:
>> Andy Fleming wrote:
>> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>> >
>> > 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.
>> >
>> > 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 8f944e5..8fed4bb 100644
>> > --- a/drivers/net/ucc_geth.c
>> > +++ b/drivers/net/ucc_geth.c
>> > @@ -113,10 +113,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,
>>
>> Is this still needed?
>>
>> I found this buried in my inbox.
>>
>> If so, please resend with the "+8" converted into a named constant.
>> Hardcoding lengths like this without named constants (or comments, on
>> the other lines) tends to be an error-prone practice.
>
> Yes, it is. I do recall the maintainer had some comments though.
> Secondly, I think it should be changed to 8 extra bytes so
> you can fit VLAN+pppoe=4+8 bytes. Possibly it could
> be configuarble at complile time.
>
> Andy, you think you can work out the details with the maintainer?
> I am much to busy ATM.


Hmm... me, too.  I'm not really familiar with this driver.  I suspect
that all of the stuff in that structure should be yanked out, and done
more sensibly, but I don't have time to do it.  I'll ping him about
it.

Andy

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

[Joakim Tjernlund]

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.

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

[Benny Amorsen]

Joakim Tjernlund <Joakim.Tjernlund@transmode.se> writes:

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

What about QinQ -- the 4 extra bytes handle that? If the limit can be
raised so easily, why have a static limit at all?


/Benny

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

[Li Yang]

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

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

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

[Joakim Tjernlund]

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

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

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