From: Ben Greear <greearb@candelatech.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: David Miller <davem@davemloft.net>,
Michael Chan <mchan@broadcom.com>,
netdev@vger.kernel.org
Subject: Re: RFC - should network devices trim frames > soft mtu
Date: Wed, 31 Aug 2011 15:26:14 -0700 [thread overview]
Message-ID: <4E5EB506.6000409@candelatech.com> (raw)
In-Reply-To: <20110831151823.23cfb7bc@nehalam.ftrdhcpuser.net>
On 08/31/2011 03:18 PM, 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.
Maybe that lets them use some kind of offload?
Either way, seems the pkt should be allowed to come up the
stack if the NIC can receive it and it's not otherwise funky.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-08-31 22:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-31 22:18 RFC - should network devices trim frames > soft mtu Stephen Hemminger
2011-08-31 22:26 ` Ben Greear [this message]
2011-08-31 22:27 ` Michael Chan
2011-09-01 0:10 ` David Lamparter
2011-08-31 22:45 ` Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E5EB506.6000409@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@davemloft.net \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox