On 2021/8/23 23:04, Eric Dumazet wrote:
On Mon, Aug 23, 2021 at 2:25 AM Yunsheng Lin linyunsheng@huawei.com wrote:
On 2021/8/18 17:36, Yunsheng Lin wrote:
On 2021/8/18 16:57, Eric Dumazet wrote:
On Wed, Aug 18, 2021 at 5:33 AM Yunsheng Lin linyunsheng@huawei.com wrote:
This patchset adds the socket to netdev page frag recycling support based on the busy polling and page pool infrastructure.
I really do not see how this can scale to thousands of sockets.
tcp_mem[] defaults to ~ 9 % of physical memory.
If you now run tests with thousands of sockets, their skbs will consume Gigabytes of memory on typical servers, now backed by order-0 pages (instead of current order-3 pages) So IOMMU costs will actually be much bigger.
As the page allocator support bulk allocating now, see: https://elixir.bootlin.com/linux/latest/source/net/core/page_pool.c#L252
if the DMA also support batch mapping/unmapping, maybe having a small-sized page pool for thousands of sockets may not be a problem? Christoph Hellwig mentioned the batch DMA operation support in below thread: https://www.spinics.net/lists/netdev/msg666715.html
if the batched DMA operation is supported, maybe having the page pool is mainly benefit the case of small number of socket?
Are we planning to use Gigabyte sized page pools for NIC ?
Have you tried instead to make TCP frags twice bigger ?
Not yet.
This would require less IOMMU mappings. (Note: This could require some mm help, since PAGE_ALLOC_COSTLY_ORDER is currently 3, not 4)
I am not familiar with mm yet, but I will take a look about that:)
It seems PAGE_ALLOC_COSTLY_ORDER is mostly related to pcp page, OOM, memory compact and memory isolation, as the test system has a lot of memory installed (about 500G, only 3-4G is used), so I used the below patch to test the max possible performance improvement when making TCP frags twice bigger, and the performance improvement went from about 30Gbit to 32Gbit for one thread iperf tcp flow in IOMMU strict mode,
This is encouraging, and means we can do much better.
Even with SKB_FRAG_PAGE_ORDER set to 4, typical skbs will need 3 mappings
- One for the headers (in skb->head)
- Two page frags, because one TSO packet payload is not a nice power-of-two.
The first issue can be addressed using a piece of coherent memory (128 or 256 bytes per entry in TX ring). Copying the headers can avoid one IOMMU mapping, and improve IOTLB hits, because all slots of the TX ring buffer will use one single IOTLB slot.
Acctually, the hns3 driver has implemented the bounce buffer for the above case, see: https://elixir.bootlin.com/linux/v5.14-rc7/source/drivers/net/ethernet/hisil...
Enabling the header buffer copying, the performance only improve from about 30Gbit to 32Gbit for one thread iperf tcp flow.
So it seems the IOMMU overhead does not only related to how many frag does a skb have, but also related to the length of each frag, as the IOMMU mapping is based on 4K/2M granularity(for arm64), so it may still take a lot of time to write each 4K page entry to the page table when mapping and invalidate each 4K page entry when unmapping.
Also, hns3 driver implement the dma_map_sg() to reduce the number of IOMMU mapping/unmapping, the peformance is only about 10%, possibly due to the above reason too, see: https://lkml.org/lkml/2021/6/16/134
The second issue can be solved by tweaking a bit skb_page_frag_refill() to accept an additional parameter so that the whole skb payload fits in a single order-4 page.
I am not sure I understand the above. Are you suggesting passing 'copy' to skb_page_frag_refill(), so that it will allocate a new pages if there is no enough buffer for the caller?
and using the pfrag pool, the improvement
went from about 30Gbit to 40Gbit for the same testing configuation:
Yes, but you have not provided performance number when 200 (or 1000+) concurrent flows are running.
As the iperf seems to only support 200 concurrent flows(running more threads seems to cause "Connection timed out"), any other performance tool supporting 1000+ concurrent flows?
There is 32 cpus on the numa where the nic hw exists, and using taskset to run the iperf in the same numa, as the page pool support page frag for rx now, so the allocating the multi-order pages as skb_page_frag_refill() does won't waste memory any more.
The below is the performance data for 200 concurrent iperf tcp flows for one tx queue: throughput node cpu usages pfrag_pool disabled: 31Gbit 5% pfrag_pool-page order 0: 43Gbit 8% pfrag_pool-page order 1: 50Gbit 8% pfrag_pool-page order 2: 70Gbit 10% pfrag_pool-page order 3: 90Gbit 11%
The below is the performance data for 200 concurrent iperf tcp flows for 32 tx queues(94.1Gbit is tcp flow line speed for 100Gbit port with mtu 1500): throughput node cpu usages pfrag_pool disabled: 94.1Gbit 23%% pfrag_pool-page order 0: 93.9Gbit 31% pfrag_pool-page order 1: 94.1Gbit 24% pfrag_pool-page order 2: 94.1Gbit 23% pfrag_pool-page order 3: 94.1Gbit 16%
So it seems page pool for tx seems promising for large number of sockets too?
Optimizing singe flow TCP performance while killing performance for the more common case is not an option.
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index fcb5355..dda20f9 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -37,7 +37,7 @@
- coalesce naturally under reasonable reclaim pressure and those which
- will not.
*/ -#define PAGE_ALLOC_COSTLY_ORDER 3 +#define PAGE_ALLOC_COSTLY_ORDER 4
enum migratetype { MIGRATE_UNMOVABLE, diff --git a/net/core/sock.c b/net/core/sock.c index 870a3b7..b1e0dfc 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -2580,7 +2580,7 @@ static void sk_leave_memory_pressure(struct sock *sk) } }
-#define SKB_FRAG_PAGE_ORDER get_order(32768) +#define SKB_FRAG_PAGE_ORDER get_order(65536) DEFINE_STATIC_KEY_FALSE(net_high_order_alloc_disable_key);
/**
diff --git a/net/core/sock.c b/net/core/sock.c index a3eea6e0b30a7d43793f567ffa526092c03e3546..6b66b51b61be9f198f6f1c4a3d81b57fa327986a 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -2560,7 +2560,7 @@ static void sk_leave_memory_pressure(struct sock *sk) } }
-#define SKB_FRAG_PAGE_ORDER get_order(32768) +#define SKB_FRAG_PAGE_ORDER get_order(65536) DEFINE_STATIC_KEY_FALSE(net_high_order_alloc_disable_key);
/**
Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an email to linuxarm-leave@openeuler.org
.