netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Sergei Antonov <saproj@gmail.com>,
	netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com
Subject: Re: [PATCH v4 net-next] net: ftmac100: support mtu > 1500
Date: Mon, 24 Oct 2022 19:21:45 +0300	[thread overview]
Message-ID: <20221024162145.4t35ucrwpafbyhbc@skbuf> (raw)
In-Reply-To: <Y1a4no+U1cbXAWLi@lunn.ch>

On Mon, Oct 24, 2022 at 06:09:02PM +0200, Andrew Lunn wrote:
> On Mon, Oct 24, 2022 at 06:50:31PM +0300, Sergei Antonov wrote:
> > On Wed, 19 Oct 2022 at 21:42, Vladimir Oltean <olteanv@gmail.com> wrote:
> > >
> > > On Wed, Oct 19, 2022 at 09:36:21PM +0300, Sergei Antonov wrote:
> > > > On Wed, 19 Oct 2022 at 19:55, Vladimir Oltean <olteanv@gmail.com> wrote:
> > > > >
> > > > > On Wed, Oct 19, 2022 at 07:20:58PM +0300, Sergei Antonov wrote:
> > > > > > The ftmac100 controller considers some packets FTL (frame
> > > > > > too long) and drops them. An example of a dropped packet:
> > > > > > 6 bytes - dst MAC
> > > > > > 6 bytes - src MAC
> > > > > > 2 bytes - EtherType IPv4 (0800)
> > > > > > 1504 bytes - IPv4 packet
> > > > >
> > > > > Why do you insist writing these confusing messages?
> > 
> > Working on a better version of the patch. And here is another question.
> > Unless the flag is set, the controller drops packets bigger than 1518
> > (that is 1500 payload + 14 Ethernet header + 4 FCS). So if mtu is 1500
> > the driver can enable the controller's functionality (clear the
> > FTMAC100_MACCR_RX_FTL flag) and save CPU time. When mtu is less or
> > greater than 1500, should the driver do the following:
> > if (ftmac100_rxdes_frame_length(rxdes) > netdev->mtu + ETH_HLEN) {
> >     drop the packet
> > }
> > I mean, is it driver's duty to drop oversized packets?
> 
> It is not well defined what should happen here. Some drivers will
> deliver oversized packets to the stack, some will not.
> 
> The main purpose of the MTU is fragmentation on transmission. How do
> you break a UDP or TCP PDU up into L2 frames. MTU is not really used
> on reception. If the L2 frame is otherwise valid, i doubt the stack
> will drop it if it is longer than expected.
> 
>      Andrew

I think the general wisdom is for a driver to not go out of its way to
accept packets larger than the MTU, and not go out of its way to drop
them either. The only given guarantee is that packets with an L2 length
<= dev->mtu are accepted.

The sad reality is that some layers like DSA rely on this marginal
behavior in some cases (controllers accept packets slightly larger than
dev->mtu) and this is why we took the decisions that we took (discussion
which I linked to in the v2 of this patch:
https://patchwork.ozlabs.org/project/netdev/patch/20200421123110.13733-2-olteanv@gmail.com/)

  reply	other threads:[~2022-10-24 20:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 16:20 [PATCH v4 net-next] net: ftmac100: support mtu > 1500 Sergei Antonov
2022-10-19 16:25 ` Sergei Antonov
2022-10-19 16:55 ` Vladimir Oltean
2022-10-19 18:36   ` Sergei Antonov
2022-10-19 18:42     ` Vladimir Oltean
2022-10-24 15:50       ` Sergei Antonov
2022-10-24 16:09         ` Andrew Lunn
2022-10-24 16:21           ` Vladimir Oltean [this message]
2022-10-24 16:24             ` Vladimir Oltean

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=20221024162145.4t35ucrwpafbyhbc@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saproj@gmail.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;
as well as URLs for NNTP newsgroup(s).