Thread (5 messages) 5 messages, 5 authors, 2011-09-01

Re: RFC - should network devices trim frames > soft mtu

From: "Michael Chan" <mchan@broadcom.com>
Date: 2011-08-31 22:35:20

On Wed, 2011-08-31 at 15:18 -0700, Stephen Hemminger wrote:
I noticed the following in the bnx2 driver.


static int
bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi, int budget)
{
...
		skb->protocol = eth_type_trans(skb, bp->dev);

		if ((len > (bp->dev->mtu + ETH_HLEN)) &&
			(ntohs(skb->protocol) != 0x8100)) {

			dev_kfree_skb(skb);
			goto next_rx;

		}

This means that for non-VLAN tagged frames, the device drops received
packets if the length is greater than the MTU.  I don't see that in
other devices. What is the correct method? IMHO the bnx2 driver is
wrong here and if the policy is desired it should be enforced at
the next level (netif_receive_skb).  Hardcoding a protocol value is
kind of a giveaway that something is fishy.
I guess the reasoning is that we program the RX MTU in our chip to
automatically discard packets bigger than the RX MTU and count them as
over-size packets.  We add 4 bytes to the RX MTU to account for the VLAN
tag which may be stripped or not stripped by the chip depending on
settings.  The extra 4 bytes in the RX MTU setting will allow over-size
packets by up to 4 bytes to get through.

I agree we should move this to the next level.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help