From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC47B34679A for ; Wed, 5 Nov 2025 20:08:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762373291; cv=none; b=tMWj3MewRIHGX8BxrXSnfemaknAVX48+YeW2FoW61MK+hj/eNtp2xQhowl9E3CShTz1Vr8kPQdennkXn0M6VffRYNqlQzdJzda6XsjZfwUyo5CJDaZC+zTm9OsEfzcxT7h+ah58J3wCjlszTMqxdjjNIU17P+xfMQzNsrcUPTqk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762373291; c=relaxed/simple; bh=n3os+k4QqkzkjBHpscj0Pon1HDkYiwHI5oh2gSfO3eA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=d6cPe+IvYmZd1/obYl6hOXAS2KhOSgVn6zMewXk9QrfXAf9DmRD29WGAjLQCw8WVFY0yjgj8FzKtLkp9+0UcZM7b0K5Iy84YgfCG+Q7UDhKw4Q2n1X82+bt14PPViPMvfiItcO7+HoVTrHbvN70tTvAHYatXdYExlopQoosNomE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--almasrymina.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=m8352Edw; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--almasrymina.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="m8352Edw" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b9a72a43e42so134387a12.2 for ; Wed, 05 Nov 2025 12:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1762373289; x=1762978089; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=tsYTHqHcd87Px6g2etcm588RqeZ8ybpTCrwlTD/0dmA=; b=m8352EdwkyOgg9FYO9mxPhyzcd9MSHAbuT3STBxALVeIKv0dZ1XHb+Qt4tBY5zm2sy El+mUKXyj/Rqr+VDmOIuRw/IAVxKJ09RuJK3IRA3wXrrOB0C8ljGV8XJqHu6xJUagnET VNfCWQ6Kcfx3J1fso/xpNfqhIaY5I65v0Q54SXGJrX3D9iTinIxrmf+vCro4AVrdggue EspaOU1I6GIMveX3JPmrgZ+1cFQMZnnJgexueAHKFFfxyHHsIIDW0voMqG93gfTG80w9 LmCIQeSjOoLLicygkEL19hPMZQ4aOU8CWUCJRAXj6eLynt8LkklrmLjGCWd9jAA38F04 lpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762373289; x=1762978089; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tsYTHqHcd87Px6g2etcm588RqeZ8ybpTCrwlTD/0dmA=; b=c0LoMow2kbJHgFsshV4SX1LHqBvAOewopXYkvvCuHr9u4KQ9dr1M+GCTqDGCeU57kL MZOVfiWbYzdHagds3JmKOZNxukfzPKOL60qgqQqwWnuSAz0s3L/wvuGZm8hSdYl0CPla riBAoEVw7ZRBbxZdQ2CY2xUuTczkuLCDR15S/NuGQy2sYBCpfMK3x7w7fzWuJwAtxSIt PRYr0Wy091SGG5tOHBOhEoODf72rckY9yNkjpGx+OK3vrO8568THFDVij4JO0CamIfsm jxBHzmPn9z6EnQ3tRisiHJ/jWVaVoPQ+DuMGccxNir/OzX2PhXUS/2ihkaiWlv06QRCC u+kw== X-Forwarded-Encrypted: i=1; AJvYcCUOg+GCePpYY8RswmZBi97JOSpYw0eNgdeIUR+K9vUhpDL6u7Z3wCT9Jkd5aLh+Yk7YMDjAItPbb7/qg5U=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1+LYxidQAV3oM5YKq/cs6cRloI0R2wd28GlKzAgq11RjGc4uW v98sFJrmvm5leiNQKViMmsuLpMDH/V/olz45+Xa7h9HWURFE2cgJ/EKFzVPgrKTxMecbpfE0gAR t9x/F2G6NfGWgWU7s+EdyPyK2tg== X-Google-Smtp-Source: AGHT+IFR7MYzatcpuTgTWfkgPeCwao/117d57DT7xFMktke+9nyy2N6IlS6Pz9VEWT8DicmLcYidcojAwE94zXXYMw== X-Received: from dlbvg6.prod.google.com ([2002:a05:7022:7f06:b0:119:96ef:3b41]) (user=almasrymina job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:2729:b0:340:cc06:9514 with SMTP id adf61e73a8af0-34f86e0bb65mr4218111637.57.1762373289217; Wed, 05 Nov 2025 12:08:09 -0800 (PST) Date: Wed, 5 Nov 2025 20:07:58 +0000 In-Reply-To: <20251105200801.178381-1-almasrymina@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251105200801.178381-1-almasrymina@google.com> X-Mailer: git-send-email 2.51.2.1026.g39e6a42477-goog Message-ID: <20251105200801.178381-2-almasrymina@google.com> Subject: [PATCH net v1 2/2] gve: use max allowed ring size for ZC page_pools From: Mina Almasry To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Mina Almasry , Joshua Washington , Harshitha Ramamurthy , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jesper Dangaard Brouer , Ilias Apalodimas , Simon Horman , Willem de Bruijn , ziweixiao@google.com, Vedant Mathur Content-Type: text/plain; charset="UTF-8" NCCL workloads with NCCL_P2P_PXN_LEVEL=2 or 1 are very slow with the current gve devmem tcp configuration. Root causing showed that this particular workload results in a very bursty pattern of devmem allocations and frees, exhausting the page_pool ring buffer. This results in sock_devmem_dontneed taking up to 5ms to free a batch of 128 netmems, as each free does not find an available entry in the pp->ring, and going all the way down to the (slow) gen_pool, and gve_alloc_buffer running into a burst of successive allocations which also don't find entries in the pp->ring (not dontneed'd yet, presumably), each allocation taking up to 100us, slowing down the napi poll loop. >From there, the slowness of the napi poll loop results, I suspect, in the rx buffers not being processed in time, and packet drops detected by tcpdump. The total sum of all this badness results in this workload running at around 0.5 GB/s, when expected perf is around 12 GB/s. This entire behavior can be avoided by increasing the pp->ring size to the max allowed 16384. This makes the pp able to handle the bursty alloc/frees of this particular workload. AFACT there should be no negative side effect of arbitrarily increasing the pp->ring size in this manner for ZC configs - the memory is prealloced and pinned by the memory provider anyway. Tested by running AllToAll PXN=2 workload. Before: Avg bus bandwidth : 0.434191 After: Avg bus bandwidth : 12.5494 Note that there is more we can do to optimize this path, such as bulk netmem dontneeds, bulk netmem pp refills, and possibly taking a page from the iouring zcrx playbook and replacing the gen_pool with a simpler fixed-size array based allocator, but this seems sufficient to fix these critcal workloads. With thanks to Willem and Eric for helping root cause this, Cc: ziweixiao@google.com Fixes: 62d7f40503bc ("gve: support unreadable netmem") Reported-by: Vedant Mathur Signed-off-by: Mina Almasry --- drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c b/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c index 0e2b703c673a..f63ffdd3b3ba 100644 --- a/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c +++ b/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c @@ -8,6 +8,8 @@ #include "gve.h" #include "gve_utils.h" +#include "net/netdev_queues.h" + int gve_buf_ref_cnt(struct gve_rx_buf_state_dqo *bs) { return page_count(bs->page_info.page) - bs->page_info.pagecnt_bias; @@ -263,6 +265,8 @@ struct page_pool *gve_rx_create_page_pool(struct gve_priv *priv, if (priv->header_split_enabled) { pp.flags |= PP_FLAG_ALLOW_UNREADABLE_NETMEM; pp.queue_idx = rx->q_num; + if (netif_rxq_has_unreadable_mp(priv->dev, rx->q_num)) + pp.pool_size = PAGE_POOL_MAX_RING_SIZE; } return page_pool_create(&pp); -- 2.51.2.1026.g39e6a42477-goog