Re: Gianfar : Drop a long frame

[Claudiu Manoil <claudiu.manoil@freescale.com>]

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