From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [RFC] tulip VLAN support Date: Wed, 05 Jan 2005 17:45:28 -0500 Message-ID: <41DC6E08.3080507@pobox.com> References: <20050105193425.GY18847@sventech.com> <41DC6669.9090407@pobox.com> <20050105223147.GE18847@sventech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@oss.sgi.com Return-path: To: Johannes Erdfelt In-Reply-To: <20050105223147.GE18847@sventech.com> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org Johannes Erdfelt wrote: > On Wed, Jan 05, 2005, Jeff Garzik wrote: > >>Johannes Erdfelt wrote: >> >>>@@ -259,7 +259,7 @@ >>>#define RX_RING_SIZE 128 >>>#define MEDIA_MASK 31 >>> >>>-#define PKT_BUF_SZ 1536 /* Size of each temporary Rx buffer. >>>*/ >>>+#define PKT_BUF_SZ 1540 /* Size of each temporary Rx buffer. >>>*/ >> >>This is the reason why the tulip "vlan" patch is continually rejected. >>You shouldn't need to increase this constant, but rather follow the >>other "large MTU" driver conversions. > > > Donald replied to my privately with a number of reasons why similar > patches have been rejected and this one of the same points brought up. > > I just copied the 2.4 patch that worked so well for me, but I was > curious about this part of the patch as well. > > I asked Donald this, but I guess I'll ask on the list here too. If the > point of PKT_BUF_SZ is to keep a consistent buffer size between drivers > (for performance reasons), why isn't this value defined in a standard > header? > > >>Donald Becker's tulip.c (on which the kernel tulip is based) supports >>proper MTU changing: ftp://ftp.scyld.com/pub/network/ > > > The problem isn't changing the MTU, it's that a full ethernet sized > packet along with the 802.1q tagging causes the size of the packet to > grow past the size the driver (and it looks like the chip) will allow. What size do you need? 1504 bytes, right? > The driver on Donald's site looks to have the same problem as the driver > in the kernel. > > I'm still trying to find some specs on the tulip interface so I can > better understand the chip and the changes necessary to fix this > problem. Anyone have any pointers? They're available for free on the Intel site. I mirror 21143: http://gkernel.sourceforge.net/specs/intel/21143-hrm.pdf.bz2 Jeff