|
|
Re: [PATCH v2] RPS: Sparse connection optimizations - v2 |
On 05/04/2012 03:47 PM, Eric Dumazet wrote:
On Fri, 2012-05-04 at 12:25 +0800, Deng-Cheng Zhu wrote:On 05/04/2012 11:22 AM, Tom Herbert wrote:+struct cpu_flow { + struct net_device *dev; + u32 rxhash; + unsigned long ts; +};This seems like overkill, we already have the rps_flow_table and this used in accelerated RFS so the device can also take advantage of steering.I think the mechanisms of rps_dev_flow_table and cpu_flow (in this patch) are different: The former works along with rps_sock_flow_table whose CPU info is based on recvmsg by the application. But for the tests like what I did, there's no application involved. Deng-ChengI really suggest you speak with MIPS arch maintainers about these IRQ being all serviced by CPU0.
This is not about arch, it's about system design. Even with IRQ affinity working, for single queue NICs, RPS still has its value in this test.
Adding tweaks in network stack to lower the impact of this huge problem is a no go.
This is merely an option, to whom care about sparse flow throughput. And it's absolutely sort of tradeoff, and not selected by default. Deng-Cheng -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Kernel Discussion] [Ethernet Bridging] [Linux Wireless Networking] [Linux Bluetooth Networking] [Linux Networking Users] [VLAN] [Git] [IETF Annouce] [Linux Assembly] [Security] [Bugtraq] [Photo] [Singles Social Networking] [Yosemite Information] [MIPS Linux] [ARM Linux Kernel] [ARM Linux] [Linux Virtualization] [Linux Security] [Linux IDE] [Linux RAID] [Linux SCSI] [Free Dating]
![]() |
![]() |