tulip VLAN support
Subsystems (2)
RFC 1/1 tulip VLAN support
I recently upgraded a system running a 2.4 kernel to a 2.6 based distribution (Fedora Core 2, 2.6.9-1.6_FC2 kernel) and ran into a problem using NFS. After spending some tracking it down, I found out it was an MTU problem and then remembered I had the same problem a couple of years ago with the 2.4 kernels I was running.
The problem is that the tulip driver doesn't handle 802.1q tags correctly. Since the VLAN tagging adds 4 bytes to the beginning of the frame, this can cause frame sizes to be too large for the driver (chip?) and the packets get dropped.
I've taken the 2.4 patch I found (I forget who developed it, sorry) and ported it to the 2.6 driver. The patch is relative to the 2.6.9-1.6_FC2 kernel for FC2, but I suspect it will apply to other kernels relatively cleanly.
Before I rediff the patch against the BK tree and double check all of the tulip variants are updated correctly as well, is there any interest in accepting a patch like this?
The 2.4 patch worked for a couple of years for me with no problems and this 2.6 patch has worked for over a week now with no problems. However, I'm worried that there is a reason why a similar patch has not been applied already.
JE
drivers/net/tulip/interrupt.c +10 -10
@@ -155,9 +155,9 @@if (--rx_work_limit <0 ) goto not_done; -if ((status &0x38008300 ) !=0x0300 ) { -if ((status &0x38000300 ) !=0x0300 ) { -/* Ingore earlier buffers. */ +if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) { +if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) { +/* Ignore earlier buffers. */ if ((status &0xffff ) !=0x7fff ) {if (tulip_debug >1 ) printk(KERN_WARNING "%s: Oversized Ethernet frame "
@@ -182,10 +182,10 @@struct sk_buff *skb;#ifndef final_version -if (pkt_len >1518 ) { +if (pkt_len >1522 ) {printk (KERN_WARNING "%s: Bogus packet size of %d (%#x).\n" , dev->name, pkt_len, pkt_len); - pkt_len =1518 ; + pkt_len =1522 ; tp->stats.rx_length_errors++; }#endif
@@ -378,9 +378,9 @@ dev->name, entry, status);if (--rx_work_limit <0 )break ; -if ((status &0x38008300 ) !=0x0300 ) { -if ((status &0x38000300 ) !=0x0300 ) { -/* Ingore earlier buffers. */ +if ((status & (0x38000000 | RxDescFatalErr | RxWholePkt)) != RxWholePkt) { +if ((status & (0x38000000 | RxWholePkt)) != RxWholePkt) { +/* Ignore earlier buffers. */ if ((status &0xffff ) !=0x7fff ) {if (tulip_debug >1 ) printk(KERN_WARNING "%s: Oversized Ethernet frame "
@@ -405,10 +405,10 @@struct sk_buff *skb;#ifndef final_version -if (pkt_len >1518 ) { +if (pkt_len >1522 ) {printk (KERN_WARNING "%s: Bogus packet size of %d (%#x).\n" , dev->name, pkt_len, pkt_len); - pkt_len =1518 ; + pkt_len =1522 ; tp->stats.rx_length_errors++; }#endif
drivers/net/tulip/tulip.h +2 -2
@@ -191,7 +191,7 @@enum desc_status_bits { DescOwned =0x80000000 , - RxDescFatalErr =0x8000 , + RxDescFatalErr =0x4842 , RxWholePkt =0x0300 , };
@@ -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. */ #define TULIP_MIN_CACHE_LINE 8/* in units of 32-bit words */
drivers/net/tulip/tulip_core.c +1 -1
@@ -70,7 +70,7 @@#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \ || defined(__sparc_) || defined(__ia64__) \ || defined(__sh__) || defined(__mips__) -static int rx_copybreak =1518 ; +static int rx_copybreak =1522 ;#else static int rx_copybreak =100 ;#endif
drivers/net/tulip/tulip.h line 262
Quoted 6 lines · Johannes Erdfelt
drivers/net/tulip/tulip.h +1
-1@@ -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 Becker's tulip.c (on which the kernel tulip is based) supports proper MTU changing: ftp://ftp.scyld.com/pub/network/
Jeff
Quoted 5 lines · Jeff Garzik
Quoted 3 lines · Johannes Erdfelt
(quoted diff) +0
-0@@ -259,7 +259,7 @@ #define RX_RING_SIZE 128 #define MEDIA_MASK 31
Quoted 8 lines
Quoted 4 lines
(quoted diff) +0
-1-#define PKT_BUF_SZ 1536 /* Size of each temporary Rxbuffer. */
+#definePKT_BUF_SZ1540 /* 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.
Has anyone tried just leaving this line as it was (but adding the rest of the patch)? I believe the 1536 already has plenty of space and can hold the extra 4 bytes w/out problem.
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 5 lines · Jeff Garzik
Quoted 4 lines · Johannes Erdfelt
drivers/net/tulip/tulip.h +0
-0@@ -259,7 +259,7 @@#define RX_RING_SIZE 128#define MEDIA_MASK 31
Quoted 8 lines
Review line 264
Quoted 4 lines
(quoted diff) +1
-1-#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?
Quoted 2 lines
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.
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?
JE
Quoted 27 lines · Johannes Erdfelt
Quoted 11 lines · Jeff Garzik
Review line 263
Quoted 7 lines · Johannes Erdfelt
(quoted diff) +1
-1@@ -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_SZis to keep a consistent buffer size between drivers (for performance reasons), why isn't this value defined in a standard header?
Quoted 6 lines
Quoted 1 line
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?
Quoted 6 lines
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
Quoted 2 lines
What size do you need? 1504 bytes, right?
1500 MTU + 14 for header + 4 for CRC + 4 for VLAN == 1522
Normally, you just have to tell the chip to accept slightly larger frames and/or ignore the over-size frame flag. You do not actually need any ability to set a larger than 1500 MTU.
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com