* Gianfar : Drop a long frame
@ 2013-01-30 13:43 voncken
2013-01-30 15:55 ` Claudiu Manoil
0 siblings, 1 reply; 5+ messages in thread
From: voncken @ 2013-01-30 13:43 UTC (permalink / raw)
To: 'Claudiu Manoil'; +Cc: netdev
Hi Claudiu,
I have a problem with the gianfar driver.
My test conditions are:
- Disable rxvlan hardware acceleration (ethtool -K ethx
rxvlan off)
- Receive frame contains a VLAN tag and with a frame len set
to the MTU (1500 bytes).
In this condition, when I received a long frame the bdp->length is
set to 1538 bytes.
I guess it is composed of:
1500 bytes: L3 data bytes
+ 14 bytes: Ethernet header
+ 4 bytes: Vlan Tag header
+ 8 bytes: FCB structure size GMAC_FCB_LEN
+ 8 bytes: eTSEC padding
+ 4 bytes: Frames CRC (FCS)
The Maximum frame len is set to 1536 because the function
gfar_change_mtu does not integrate the FCS in the computed frame size.
In this condition this frame is dropped with the test line 2792
function gfar_clean_rx_ring
if (unlikely(!(bdp->status & RXBD_ERR) &&
bdp->length > priv->rx_buffer_size))
bdp->status = RXBD_LARGE;
How I can receive this frame correctly?
Best regards
Cedric Voncken | R&d Engineer
----------------------------------------------------------------------------
------------------------------
T : +33 1 30 56 46 52
cedric.voncken@acksys.fr | www.acksys.fr
----------------------------------------------------------------------------
------------------------------
ZA Val Joyeux - 10 rue des Entrepreneurs - 78450 VILLEPREUX - France
----------------------------------------------------------------------------
----------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gianfar : Drop a long frame
2013-01-30 13:43 Gianfar : Drop a long frame voncken
@ 2013-01-30 15:55 ` Claudiu Manoil
2013-01-30 16:27 ` voncken
0 siblings, 1 reply; 5+ messages in thread
From: Claudiu Manoil @ 2013-01-30 15:55 UTC (permalink / raw)
To: voncken; +Cc: netdev
On 1/30/2013 3:43 PM, voncken wrote:
> Hi Claudiu,
>
> I have a problem with the gianfar driver.
>
> My test conditions are:
> - Disable rxvlan hardware acceleration (ethtool -K ethx
> rxvlan off)
> - Receive frame contains a VLAN tag and with a frame len set
> to the MTU (1500 bytes).
>
> In this condition, when I received a long frame the bdp->length is
> set to 1538 bytes.
> I guess it is composed of:
> 1500 bytes: L3 data bytes
> + 14 bytes: Ethernet header
> + 4 bytes: Vlan Tag header
> + 8 bytes: FCB structure size GMAC_FCB_LEN
> + 8 bytes: eTSEC padding
> + 4 bytes: Frames CRC (FCS)
>
> The Maximum frame len is set to 1536 because the function
> gfar_change_mtu does not integrate the FCS in the computed frame size.
> In this condition this frame is dropped with the test line 2792
> function gfar_clean_rx_ring
> if (unlikely(!(bdp->status & RXBD_ERR) &&
> bdp->length > priv->rx_buffer_size))
> bdp->status = RXBD_LARGE;
>
> How I can receive this frame correctly?
>
> Best regards
>
> Cedric Voncken | R&d Engineer
Hi Cedric Voncken,
Is the 802.1Q support activated on the receiving host? (see
CONFIG_VLAN_8021Q)
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Gianfar : Drop a long frame
2013-01-30 15:55 ` Claudiu Manoil
@ 2013-01-30 16:27 ` voncken
2013-01-31 8:50 ` Claudiu Manoil
0 siblings, 1 reply; 5+ messages in thread
From: voncken @ 2013-01-30 16:27 UTC (permalink / raw)
To: 'Claudiu Manoil'; +Cc: netdev
-----Message d'origine-----
De : Claudiu Manoil [mailto:claudiu.manoil@freescale.com]
Envoyé : mercredi 30 janvier 2013 16:56
À : voncken
Cc : netdev@vger.kernel.org
Objet : Re: Gianfar : Drop a long frame
On 1/30/2013 3:43 PM, voncken wrote:
> Hi Claudiu,
>
> I have a problem with the gianfar driver.
>
> My test conditions are:
> - Disable rxvlan hardware acceleration (ethtool -K ethx
rxvlan off)
> - Receive frame contains a VLAN tag and with a frame len set
to the
> MTU (1500 bytes).
>
> In this condition, when I received a long frame the bdp->length is
> set to 1538 bytes.
> I guess it is composed of:
> 1500 bytes: L3 data bytes
> + 14 bytes: Ethernet header
> + 4 bytes: Vlan Tag header
> + 8 bytes: FCB structure size GMAC_FCB_LEN
> + 8 bytes: eTSEC padding
> + 4 bytes: Frames CRC (FCS)
>
> The Maximum frame len is set to 1536 because the function
> gfar_change_mtu does not integrate the FCS in the computed frame size.
> In this condition this frame is dropped with the test line 2792
> function gfar_clean_rx_ring
> if (unlikely(!(bdp->status & RXBD_ERR) &&
> bdp->length > priv->rx_buffer_size))
> bdp->status = RXBD_LARGE;
>
> How I can receive this frame correctly?
>
> Best regards
>
> Cedric Voncken | R&d Engineer
Hi Cedric Voncken,
Is the 802.1Q support activated on the receiving host? (see
CONFIG_VLAN_8021Q)
Hi Claudiu,
YEs the CONFIG_VLAN_8021Q is enable on the receiving host, that work
correctly if RXVLAN is set to on (ethtool -K ethx rxvlan off)
I try with the linux kernel 3.3.8.
Regards.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gianfar : Drop a long frame
2013-01-30 16:27 ` voncken
@ 2013-01-31 8:50 ` Claudiu Manoil
2013-01-31 14:13 ` voncken
0 siblings, 1 reply; 5+ messages in thread
From: Claudiu Manoil @ 2013-01-31 8:50 UTC (permalink / raw)
To: voncken; +Cc: netdev
On 1/30/2013 6:27 PM, voncken wrote:
> -----Message d'origine-----
> De : Claudiu Manoil [mailto:claudiu.manoil@freescale.com]
> Envoyé : mercredi 30 janvier 2013 16:56
> À : voncken
> Cc : netdev@vger.kernel.org
> Objet : Re: Gianfar : Drop a long frame
>
> On 1/30/2013 3:43 PM, voncken wrote:
>> Hi Claudiu,
>>
>> I have a problem with the gianfar driver.
>>
>> My test conditions are:
>> - Disable rxvlan hardware acceleration (ethtool -K ethx
> rxvlan off)
>> - Receive frame contains a VLAN tag and with a frame len set
> to the
>> MTU (1500 bytes).
>>
>> In this condition, when I received a long frame the bdp->length is
>> set to 1538 bytes.
>> I guess it is composed of:
>> 1500 bytes: L3 data bytes
>> + 14 bytes: Ethernet header
>> + 4 bytes: Vlan Tag header
>> + 8 bytes: FCB structure size GMAC_FCB_LEN
>> + 8 bytes: eTSEC padding
>> + 4 bytes: Frames CRC (FCS)
>>
>> The Maximum frame len is set to 1536 because the function
>> gfar_change_mtu does not integrate the FCS in the computed frame size.
>> In this condition this frame is dropped with the test line 2792
>> function gfar_clean_rx_ring
>> if (unlikely(!(bdp->status & RXBD_ERR) &&
>> bdp->length > priv->rx_buffer_size))
>> bdp->status = RXBD_LARGE;
>>
>> How I can receive this frame correctly?
>>
>> Best regards
>>
>> Cedric Voncken | R&d Engineer
>
> Hi Cedric Voncken,
> Is the 802.1Q support activated on the receiving host? (see
> CONFIG_VLAN_8021Q)
>
> Hi Claudiu,
>
> YEs the CONFIG_VLAN_8021Q is enable on the receiving host, that work
> correctly if RXVLAN is set to on (ethtool -K ethx rxvlan off)
> I try with the linux kernel 3.3.8.
>
> Regards.
>
Ok, at fist glance it seems that the DEFAULT_RX_BUFFER_SIZE of 1536
bytes is not enough to accommodate VLAN_HLEN.
Apparently, the reason why it works with rxvlan 'on' and it doesn't
when set to 'off' is because by changing the NETIF_F_HW_VLAN_* feature
flags the gfar_change_mtu() gets called, which in turn has the following
issue:
gfar_change_mtu():
...
if (gfar_is_vlan_on(priv))
frame_size += VLAN_HLEN;
...
where,
gfar_is_vlan_on():
{
return (priv->ndev->features & NETIF_F_HW_VLAN_RX) ||
(priv->ndev->features & NETIF_F_HW_VLAN_TX);
}
and it's odd that the rx_buffer_size is conditioned by the HW VLAN
acceleration feature being turned on or off.
But I'll have to run some tests too to confirm this.
Regards,
Claudiu
^ permalink raw reply [flat|nested] 5+ messages in thread* RE: Gianfar : Drop a long frame
2013-01-31 8:50 ` Claudiu Manoil
@ 2013-01-31 14:13 ` voncken
0 siblings, 0 replies; 5+ messages in thread
From: voncken @ 2013-01-31 14:13 UTC (permalink / raw)
To: 'Claudiu Manoil'; +Cc: netdev
On 1/30/2013 6:27 PM, voncken wrote:
> -----Message d'origine-----
> De : Claudiu Manoil [mailto:claudiu.manoil@freescale.com]
> Envoyé : mercredi 30 janvier 2013 16:56 À : voncken Cc :
> netdev@vger.kernel.org Objet : Re: Gianfar : Drop a long frame
>
> On 1/30/2013 3:43 PM, voncken wrote:
>> Hi Claudiu,
>>
>> I have a problem with the gianfar driver.
>>
>> My test conditions are:
>> - Disable rxvlan hardware acceleration (ethtool -K ethx
> rxvlan off)
>> - Receive frame contains a VLAN tag and with a frame len set
> to the
>> MTU (1500 bytes).
>>
>> In this condition, when I received a long frame the bdp->length is
>> set to 1538 bytes.
>> I guess it is composed of:
>> 1500 bytes: L3 data bytes
>> + 14 bytes: Ethernet header
>> + 4 bytes: Vlan Tag header
>> + 8 bytes: FCB structure size GMAC_FCB_LEN
>> + 8 bytes: eTSEC padding
>> + 4 bytes: Frames CRC (FCS)
>>
>> The Maximum frame len is set to 1536 because the function
>> gfar_change_mtu does not integrate the FCS in the computed frame size.
>> In this condition this frame is dropped with the test line 2792
>> function gfar_clean_rx_ring
>> if (unlikely(!(bdp->status & RXBD_ERR) &&
>> bdp->length > priv->rx_buffer_size))
>> bdp->status = RXBD_LARGE;
>>
>> How I can receive this frame correctly?
>>
>> Best regards
>>
>> Cedric Voncken | R&d Engineer
>
> Hi Cedric Voncken,
> Is the 802.1Q support activated on the receiving host? (see
> CONFIG_VLAN_8021Q)
>
> Hi Claudiu,
>
> YEs the CONFIG_VLAN_8021Q is enable on the receiving host, that work
> correctly if RXVLAN is set to on (ethtool -K ethx rxvlan off) I try
> with the linux kernel 3.3.8.
>
> Regards.
>
Ok, at fist glance it seems that the DEFAULT_RX_BUFFER_SIZE of 1536 bytes is
not enough to accommodate VLAN_HLEN.
Apparently, the reason why it works with rxvlan 'on' and it doesn't when set
to 'off' is because by changing the NETIF_F_HW_VLAN_* feature flags the
gfar_change_mtu() gets called, which in turn has the following
issue:
gfar_change_mtu():
...
if (gfar_is_vlan_on(priv))
frame_size += VLAN_HLEN;
...
where,
gfar_is_vlan_on():
{
return (priv->ndev->features & NETIF_F_HW_VLAN_RX) ||
(priv->ndev->features & NETIF_F_HW_VLAN_TX); }
and it's odd that the rx_buffer_size is conditioned by the HW VLAN
acceleration feature being turned on or off.
But I'll have to run some tests too to confirm this.
Regards,
Claudiu
It's true. That work when rx is on, because the VLAN TAG is removed from
frame by eTSEC and the len frame is below 1536.
In the mpc8315 Family reference manual rev 2, the table 19-160 indicates
that if L bit is set, the data length includes the CRC. It seems the
gfar_change_mtu function must include the CRC length in frame len compute.
Best regards
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-01-31 14:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-30 13:43 Gianfar : Drop a long frame voncken
2013-01-30 15:55 ` Claudiu Manoil
2013-01-30 16:27 ` voncken
2013-01-31 8:50 ` Claudiu Manoil
2013-01-31 14:13 ` voncken
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).