Thread (5 messages) 5 messages, 2 authors, 2013-01-31

RE: Gianfar : Drop a long frame

From: voncken <hidden>
Date: 2013-01-31 14:13:41

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:
quoted
	Hi Claudiu,

	I have a problem with the gianfar driver.

	My test conditions are:
		- Disable rxvlan hardware acceleration (ethtool -K ethx
rxvlan off)
quoted
		- Receive frame contains a VLAN tag and with a frame len set
to the
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help