|
From: Auke K. <auk...@in...> - 2006-10-27 15:35:17
|
Vik Heyndrickx wrote: > Hi, > > I'm having a big problem with e1000. It sends out packets that are larger than the MTU. This causes tc (linux traffic control) to get confused: the data is going out the interface roughly three times faster than the configured rate. This problem does not exist with another nic installed in the same system. > > It's a Fedora Core 5 system upgraded to the latest packages. These are the relevant bits of information of my systems: > > # uname -a > Linux alexandria.edch 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux > > # cat /var/log/messages | grep 'e1000:' > Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:42 > Oct 27 12:19:45 alexandria kernel: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:02.0: e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:43 > Oct 27 12:19:45 alexandria kernel: e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection > Oct 27 12:19:46 alexandria kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex > Oct 27 12:19:46 alexandria kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex I prefer to see the driver version too, and really we need the full dmesg output. lspci -vv ? I'd like to know what hardware you have too. > # ip link show > 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether xx:xx:xx:xx:xx:42 brd ff:ff:ff:ff:ff:ff > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether xx:xx:xx:xx:xx:43 brd ff:ff:ff:ff:ff:ff > > This is a small portion of a packet trace (tcpdump) during an FTP download from server 10.33.1.21 to client 10.33.1.254: notice the large packets going out. so is 10.33.1.21 the e1000 NIC? this is not really clear... > 13:18:12.915056 IP (tos 0x8, ttl 64, id 42189, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42872385:42873833(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.915178 IP (tos 0x8, ttl 64, id 42190, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42873833:42875281(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.915308 IP (tos 0x8, ttl 64, id 42191, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42875281:42876729(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.916044 IP (tos 0x8, ttl 64, id 42192, offset 0, flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . 42876729:42886865(10136) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.916917 IP (tos 0x8, ttl 64, id 42199, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42886865:42894105(7240) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.917293 IP (tos 0x8, ttl 64, id 42204, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42894105:42901345(7240) ack 1 win 46 <nop,nop,timestamp 596232 304808104> > 13:18:12.918168 IP (tos 0x8, ttl 64, id 42209, offset 0, flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . 42901345:42911481(10136) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > 13:18:12.918918 IP (tos 0x8, ttl 64, id 42216, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42911481:42920169(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > 13:18:12.919667 IP (tos 0x8, ttl 64, id 42222, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42920169:42928857(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > 13:18:12.920166 IP (tos 0x8, ttl 64, id 42228, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42928857:42936097(7240) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > 13:18:12.920791 IP (tos 0x8, ttl 64, id 42233, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42936097:42944785(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > 13:18:12.921540 IP (tos 0x8, ttl 64, id 42239, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42944785:42953473(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105> > > If there a way to configure the driver not to do this? I want my packets limited to 1500 standard sized ethernet frames. the driver should adhere to the MTU for sending packets on the wire. If it isn't then it's a big bug. But right now I don't have enough information from this report to investigate, so please provide us with the extra information. Cheers, Auke > > Thanks, > |