Date: Fri, 7 Sep 2007 10:51:27 -0700 From: "David Christensen" <davidch@broadcom.com> To: "Julian Elischer" <julian@elischer.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: RE: FreeBSD discarding received packets > MTU Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <46E0A5DB.3080404@elischer.org> References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It could certainly be argued by some that Cisco is not standards > > compliant in this case for sending an oversized Ethernet frame > > and expecting everyone to accept it. Hardware has limitations > > and assuming that all Ethernet controllers can support frames > > greater than 1522 bytes is not reasonable. Fortunately there is > > a suitable workaround which is setting a larger MTU for the=20 > > interface. What size do you use? How did you arrive at that > > value? >=20 > I use 1550 to make it work in the test harness. >=20 > The trouble is that if I set the mtu to 1550, and the machine=20 > talks to another > such machine with it's mtu also set to 1550 then they=20 > negotiate a maximum sized > packet based on 1550, and the problem hits me again. This is=20 > a web proxy=20 > and that problem occurs when there are two layers of proxy=20 > and one proxy talks to=20 > another. I really just need it to to silently accept a packet some=20 > 32 bytes or so larger than the stated MTU. >=20 > I see no reason for the driver to not do what the em driver=20 > does and allow=20 > itself to receive any packet up to the MCLBYTES size. >=20 > We only hit this problem recently because the data interfaces on our > devices are usually em NICs and we only just recently started=20 > allowing the=20 > users to use the built in (on DELL 2950) bce interfaces for=20 > this purpose. >=20 I'm not completely opposed to making such a change, but I don't want to make a default change in the driver's behavior that other people=20 may be depending upon (whether they are aware of it or not). A tunable driver value could be the answer but I'm not entirely sure how it would fare in the hardware at the high end of MTU values such=20 as 9000. Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6>