Re: [E1000-devel] Reg Transmit and Receive queue
vikram wrote: > I am vikram, a graduate student in Arizona State University. > > I am trying to bring up one set up where i am using igb driver e1000, > where in i would like to send the Ip packets across all the queues > associated with the port instead just one or two. I know some hash > algorithm in kernel source code selects the queue based on some > hashing mechanism but i don't know where exactly it is. if you're using 2.6.27 or newer, tx uses simple_tx_hash function for tx queue selection. rx uses a hash in hardware called RSS. varying any of the ip source/dest, source port/dest, or protocol will help distribute to any of the tx queues. > Could some one please throw light on this. Also it would be great if > some one could tell me how to go about making the ip packets to span > across all the 4 queues instead of just one. see above. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH 1/2] igb: Implement reading of reg RQDPC (Receive Queue Drop Packet Count)
>-Original Message- >From: Jesper Dangaard Brouer [mailto:h...@comx.dk] >Sent: Monday, May 11, 2009 2:50 AM > >I have now tested it on a 82575 chip NIC. (I just got my 82575 NIC >working again (This 12 port monster from Hotlava Systems, just needed >more power on PCIe 100Watt)). > >I don't see the reason for doing special checks for the 82575. Reading >the RQDPC registers on 82575 always returns 0. I don't see any harm in >that!? (it also returns zero in overload situations) > >What do you want to redraw your NAK? > Jesper, I still stand by my NAK. It's never ever a good idea to read non-existent hardware registers. You don't know what effect those reads will have on the hardware. These addresses may be aliased to other registers without being documented. Hardware designers do this all the time to save a few gates in the address decode logic, and these aliases may or may not be documented. If this is the case, reading these registers will have unintended consequences. You might be clearing some other statistic, or worse. Since we just don't know, it's better to be safe than sorry. Wrap those register reads so they only happen on 82576, and I'll happily ack your patch. -Mitch -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Tx Unit Hang on 82540EP
zsolt foldvari wrote: > Hi! > > On Wed, Apr 8, 2009 at 2:12 AM, Brandeburg, Jesse > wrote: >> Your full dmesg from boot would have been more useful, but I think >> you have the issue of dma with these 32 bit controllers failing when >> you have lots of ram. > > dmesg_1.txt is the full output from boot. > >> do you have 4GB or greater of ram? > > I have only 512K. > >> your hardware is failing to send *all* packets, as in it never >> succeeds in sending any. this could be an interrupt problem (so >> please check /proc/interrupts and make sure you get an interrupt for >> your eth0 interface every two seconds) or a dma issue, or maybe even >> a hardware failure. > > There are many devices attached to the same interrupt (IRQ11). Any way > I can see interrupts coming only from eth0? > > Btw., I have issues with my Intel PRO Wireless too for a long time, > but I thought it was related to some kernel upgrade. When the module > is enabled I often get message "IRQ11 Disabled" and kernel locks up. > Perhaps it means interrupt problems. The e1000 and ipw2100 problems > didn't start at the same time! > >> I guess the other option could be that it doesn't like the IPv6 >> packets for some reason. > > ipv6 kernel module is not loaded. > >> we have a patch at sourceforge in the patches section, that patches >> in an e1000_dump function. This might be useful to see the output >> from. When you get a tx hang it will dump a ton of data into dmesg >> and if you could send us that it would be great. > > Please find attached the output from dmesg after the tx hang. I've > included syslog as well since the dmesg buffer seems to be too small. > > I did upgrade the BIOS to the latest available version beforehand. > > Zsolt This issue appears to have gone silent, were you able to resolve it? -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
