Re: [RFC] tulip VLAN support

[Jeff Garzik <jgarzik@xxxxxxxxx>]

Johannes Erdfelt wrote:
> On Wed, Jan 05, 2005, Jeff Garzik <jgarzik@xxxxxxxxx> 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