[E1000-devel] BUG in ixgbe_clean_rx_irq()?
Hi, last_rx is being updated only if NETIF_F_GRO is not defined - probably in view that last_rx is being updated in the kernel in GRO code related. However, this is not true. last_rx is being updated in the linux kernel in the new generic packet receive handler stuff (bond_handle_frame) which is not related to GRO and even introduced few kernel versions later than GROwhich means your latest ixgbe won't work properly with bond in kernel versions 2.6.29-2.6.38. -- Benzi. -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] ixgbe : RSS does not work for VLAN packets
Hi, I see that ALL vlan packets (with many different IPs but specific vlan id) are pushed to single queue (rx0) instead of being distributed to all rx queues like you expect from RSS feature. Is there a way to enable RSS to work also on VLAN packets? Note that without VLAN RSS works fine (distributing to all 8 rx queues). -- Benzi. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] spanning packet on multiple rx descriptors
Hi, What are the user scenario cases where packet is received on multiple rx descriptors (i guess that usually it is not the case)? How can i force it to happen? Thanks, Benzi. -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] ixgbe - high tx_restart_queue
Hi, I see this stat being increased meaning the tx ring is getting full and i want to avoid that. it might be that the cleanup of tx ring buffer is slow. In e1000 there is TxIntDelay that you recomment to lower its value for faster tx cleanup. IS there something similar for ixgbe? Thanks, Benzi -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] ixgbe - high tx_restart_queue
Flow control is disabled. Can you explain please why *decreasing* (and not increasing) the tx ring buffer will help avoiding tx_restart_queue? Regarding InterruptThrottleRate, do you mean that setting it to higher value may also prevent tx_restart_queue by faster tx ring cleanup? On Mon, Apr 20, 2009 at 9:54 PM, Brandeburg, Jesse jesse.brandeb...@intel.com wrote: Benzi wrote: Hi, I see this stat being increased meaning the tx ring is getting full and i want to avoid that. it might be that the cleanup of tx ring buffer is slow. In e1000 there is TxIntDelay that you recomment to lower its value for faster tx cleanup. IS there something similar for ixgbe? Thanks, Benzi are you using flow control? if not, the only other thing to adjust is to decrease the tx descriptor ring size (ethtool -G ... tx 256) (you'd be surprised how much speed up you can get with small packets by decreasing) and adjust the interrupt throttle rate with either the ethtool -C ... rx-usecs and/or the InterruptThrottleRate module load parameter. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
