On 27/02/2013 20:41, Eric Dumazet wrote:
> On Wed, 2013-02-27 at 09:56 -0800, Eliezer Tamir wrote:
>
>> @@ -1458,7 +1459,9 @@ static void ixgbe_rx_skb(struct ixgbe_q_vector
>> *q_vector,
>> {
>> struct ixgbe_adapter *adapter = q_vector->adapter;
>>
>> - if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL))
>> + if (ixgbe_qv_ll_polling(q_vector))
>> + netif_receive_skb(skb);
>> + else if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL))
>> napi_gro_receive(&q_vector->napi, skb);
>> else
>> netif_rx(skb);
>
> Interesting reordering issue here.
yes, we need to fix this.
Maybe force a GRO flush when spinning, or maybe disable GRO in a more
global manner when someone is busy-polling
> Why by-passing GRO stack if its enabled ?
you want to bypass GRO because it adds latency.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
