Hi Alex,
I have tested your suggestion but unfortunately it does not seem to work. I 
have verified that the value in the IXGBE_SRRCTL register is set to 12000802 
thus the drop bit should be set. Basically sending packets to the card (RSS 
balanced across RX queues), if I don't consume/read packets on all remaining 
queues (via ixgbe_clean_rx_irq), even on the queue where I am reading packets, 
the descriptors are not notifying new packets. I am using a 82598-based card.

is there anything else you suggest me to try?

Regards Luca



On May 25, 2011, at 10:08 PM, Alexander Duyck wrote:

> On 05/25/2011 06:32 PM, Luca Deri wrote:
>> Dear all
>> I am modifying the ixgbe driver for improving packet capture performance. I 
>> have noticed that in case of multiple-queue, when one RX queue is full, the 
>> card stops receiving packets for all the other queues, even if they have 
>> room for packets.
>> 
>> Is there a way I can tell the card to keep receiving packets for queue that 
>> have room for new packets (i.e. How can I tell the card to have independent 
>> queues)?
>> 
>> Thanks in advance, Luca
>> 
> I would recommend looking into the SRRCTL register and the DROP_EN bit.  By 
> setting the DROP_EN bit in the SRRCTL register the RX FIFO will drop packets 
> for stopped queues instead of back-filling the RX FIFO.  This should allow 
> the queues to function independently without any head of line blocking.
> 
> Thanks,
> 
> Alex

---
We can't solve problems by using the same kind of thinking we used when we 
created them - Albert Einstein


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
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

Reply via email to