[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314830728.3274.52.camel@bwh-desktop>
Date: Wed, 31 Aug 2011 23:45:28 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: David Miller <davem@...emloft.net>,
Michael Chan <mchan@...adcom.com>, netdev@...r.kernel.org
Subject: Re: RFC - should network devices trim frames > soft mtu
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.
According to netdevices.txt:
"MTU is symmetrical and applies both to receive and transmit. ...
The device may either: drop, truncate, or pass up oversize packets, but
dropping oversize packets is preferred."
I believe UNH interop tests expect that MRU = MTU and oversize packets
are dropped. However, I seem to recall that David has said more
recently that it's preferable to always use the maximum possible MRU if
DMA scatter is supported (so that this doesn't require page allocations
of order > 0).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists