Gregory et al,
We recently moved to using Linux kernel 3.8 & hence had to use ixgbevf
driver version 2.7.12-k. We realized that we have a huge performance
regression in most of the cases.
Our setup involves:
# ixgbevf driver over SRIOV VF
# SCST iSCSI target exposing standard linux RAMdisk
While doing 64K sequential writes, the latency of single host IO has
increased from sub 1ms to 3ms. Additionally previously (in 3.2 kernels) on
running multiple host IO threads, we were able to reach 115MB/s with
RAMDisk (115MB/s is the max we can reach with our host/network
configuration for RAMDisk). However with 2.7.12-k ixgbevf driver we were
able to reach only 60-80MB/s. This performance fluctuates very heavily.
We managed to nail down the issue is due to a ixgbevf driver regression
introduced with this patchset.
http://www.spinics.net/lists/netdev/msg216479.html
https://kernel.googlesource.com/pub/scm/linux/kernel/git/jkirsher/net-next/+/85624caff9decc8174f286e12e9d0038d9a6cced%5E
Previously we always had packets reach SCST iSCSI target in the following
way
iscsi_data_ready+0x2b/0x50 [iscsi_scst]
tcp_rcv_established+0x53b/0x7e0
tcp_v4_do_rcv+0x134/0x220
tcp_v4_rcv+0x569/0x840
ip_local_deliver_finish+0xde/0x280
ip_local_deliver+0x4a/0x90
ip_rcv_finish+0x119/0x360
ip_rcv+0x21d/0x300
__netif_receive_skb+0x602/0x760
netif_receive_skb+0x23/0x90
napi_gro_complete+0x84/0xe0
dev_gro_receive+0x1d8/0x2b0
napi_gro_receive+0x113/0x1b0
ixgbevf_clean_rx_irq+0x2bd/0x410 [ixgbevf]
ixgbevf_poll+0x9e/0x120 [ixgbevf]
net_rx_action+0x134/0x260
call_softirq+0x1c/0x30
do_softirq+0x65/0xa0
irq_exit+0x8e/0xb0
do_IRQ+0x63/0xe0
However with this flag on, we always have it delivered through
iscsi_data_ready+0x2b/0x50 [iscsi_scst]
tcp_data_queue+0x364/0x580
tcp_rcv_established+0x245/0x770
tcp_v4_do_rcv+0x134/0x220
tcp_v4_rcv+0x569/0x840
ip_local_deliver_finish+0xe6/0x280
ip_local_deliver+0x4a/0x90
ip_rcv_finish+0x119/0x360
ip_rcv+0x21d/0x300
__netif_receive_skb+0x5fa/0x760
process_backlog+0xb1/0x190
net_rx_action+0x134/0x260
call_softirq+0x1c/0x30
do_softirq+0x65/0xa0
irq_exit+0x8e/0xb0
do_IRQ+0x63/0xe0
i.e. we always requeue packets & only backlog processing pushes the packet
to SCST.
We have confirmed that by reverting this patch in 2.7.12-k ixgbevf we are
able to get back to the old performance levels in 3.8 kernels.
Kindly request you to revert this patch & get a different patch for the
jumbo frame issue.
Thanks.
PS: I am not in e1000-devel list. Pls cc any replies.
--Shyam
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
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
