Date:	Thu, 21 Jan 2010 15:02:54 -0800
From:	"Templin, Fred L" <Fred.L.Templin@...ing.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Szilveszter Ordog <slipszi@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Problems with tg3 driver after lowering the MTU

Ben,

> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: Thursday, January 21, 2010 10:30 AM
> To: Templin, Fred L
> Cc: Szilveszter Ordog; netdev@...r.kernel.org
> Subject: RE: Problems with tg3 driver after lowering the MTU
> 
> On Thu, 2010-01-21 at 09:47 -0800, Templin, Fred L wrote:
> > > -----Original Message-----
> > > From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On Behalf Of Szilveszter
> > > Ordog
> > > Sent: Thursday, January 21, 2010 7:42 AM
> > > To: netdev@...r.kernel.org
> > > Subject: Re: Problems with tg3 driver after lowering the MTU
> > >
> > > On Thu, Jan 21, 2010 at 16:27, Ben Hutchings <bhutchings@...arflare.com> wrote:
> > > > On Thu, 2010-01-21 at 16:21 +0100, Szilveszter Ordog wrote:
> > > >> After the MTU is lowered (e.g. to 1420) on a tg3-driven interface,
> > > >> received packets larger than that (e.g. 1500 bytes) are silently
> > > >> discarded by the driver. Therefore the system doesn't send ICMP
> > > >> fragmentation-needed packets and the other side doesn't detect this
> > > >> condition.
> > > >>
> > > >> Is this a known bug?
> > > >
> > > > I don't believe this a bug.  Within a local network, MTU should be set
> > > > the same for all interfaces.  Routers that connect networks with
> > > > different MTUs will generate the fragmentation-needed message as
> > > > appropriate.
> > >
> > > Other drivers do not behave like that. Most of them always allow
> > > packets smaller than 1500 bytes. That is why I think that this is a
> > > bug.
> >
> > The question seems to be what happens when the
> > Maximum Transmission Unit (MTU) is smaller than
> > the Maximum Receive Unit (MRU)?
> >
> > For TCP, MSS is calculated based on MTU (not MRU)
> > so there should not be any size mismatches with TCP.
> > For large packets of other IP protocols, it should
> > be OK for the end system to receive a packet larger
> > than it is capable of sending. So, it seems to me
> > that packets that are larger than MTU but no larger
> > than MRU should be accepted.
> 
> In theory, MRU and MTU could be quite separate.  However, there is no
> standard interface to set an interface's MRU, so where the hardware
> supports a variable MRU drivers normally set it based on the MTU.

In RFC1122, EMTU_S (i.e., the MTU) and EMTU_R (i.e., the
MRU) are maintained separately and are not specified as
dependent on one another directly. Intuitively however,
the relationship MTU <= MRU seems appropriate, and consistent
with a number of specs that require the reassembly size to
be no smaller than the interface MTU. The term "MRU" itself
came from RFC1661 (PPP) where it is the MRU and not MTU that
is negotiated.

So I see evidence to support the assertion that MTU <= MRU,
but I don't see much evidence to support the assertion that
MTU == MRU. Besides, if a packet arrives that is larger
than MTU but no larger than MRU, why throw away good data?

Fred
fred.l.templin@...ing.com
 
> Ben.
> 
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> 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