From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=FeF2ivwX; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 77E145A0008 for ; Mon, 07 Apr 2025 23:51:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744062717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J6UoxHhrPV2LVwaG/l8aAVvlVZx1GByMfPRddKYwrMk=; b=FeF2ivwXX+qk5+A5U5f6wcTdtMjjMXn/LqD/Xd/fnr2S/FNTrJTm8b0kYVgW5tqNMIIFWe h/BjTKarH5gV1/kQ4QfJYCHpKa9kTrk6nQ2/4zksGp2cqz8f4e2t/71jvFuDBHW5FQirLd R3WwMeKv+FpsctJYo5XLzrfR2/8ol4Q= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-685-f8VmNZrkNNiaDvbCgnOULg-1; Mon, 07 Apr 2025 17:49:16 -0400 X-MC-Unique: f8VmNZrkNNiaDvbCgnOULg-1 X-Mimecast-MFC-AGG-ID: f8VmNZrkNNiaDvbCgnOULg_1744062555 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43d01024089so41676485e9.1 for ; Mon, 07 Apr 2025 14:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744062555; x=1744667355; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=J6UoxHhrPV2LVwaG/l8aAVvlVZx1GByMfPRddKYwrMk=; b=pbAXuol/6IC1KV0xi2DbBFcbHAt5+XJV3Q2mcU2GX67uLu/rcoaNXXnD7lHuoTEO+v k7bl5Gs0y6SCiLehLUunpHlDG5tE324qqjpY3RKIozXmYBWsHHPI4pJECq4mtNQ9OXJL ez0bSsYuSgGrX+mfotEgmGgYaS9uDPsJCAduTcMXz0li3SvOWOMybTSuKq4Tm+zcJzWw Xb7YvPy6TFX7h2WkRWd/m8nWv8hNaAYaANJ/igUVBMJi1X+/gLiSa22xhdcMO/l3Da7u v6XRtn8wxpM5GBl2RWN5+9uV98vs4Hv4aKhvF8Tz7WjfsFWTRHzlV6ZfYYGmRvXXAYLb /uGA== X-Gm-Message-State: AOJu0YwsQSWc9l5I3CvI9UGjmYu79Ge12aGtlyidDHGq2vC036OoaA27 JPRA2GnOZXF57oPaTjiGDRH9XC9nDMGqY6tXc1VQpJMi/U6qPE4gzNyjryRTba1sjbPvgoWDldE uD4xIUvS8WgFMbnzNRDSKjV2GgmIb26wkcW+n5GSdgFAbTgUcZwS2IQivMw== X-Gm-Gg: ASbGnctIBZS18eljDAV3eL+6fYTKbmyRR3kopwZih52X2XYs0iIg84Z8VTETVXn2/Y2 IHlZYmqfkBm3ijctIXd9l7h7I9b3T0aji7Kbt3TGkAUiw4AhCxGGHHg0wAZhzgJ/SDjNpghluBc uUlsSsA7cBmoXoKYTuiOd0jaJwD3jCS6i7/iVTG1aKNhPs9n27B403foaekNHvJi0cBXjIh3FDH qhUPDh4egyeBE50HerH25oZTTh4ko1A4LF2AffSzCCdUz+A77h0zTJNgspLI+T/NpdIDlbFVUf0 EeRuAbWgih612oCBxoaSnyY7LNw= X-Received: by 2002:a05:600c:3595:b0:43d:1f1:8cd with SMTP id 5b1f17b1804b1-43ecf9c795emr122524895e9.24.1744062554823; Mon, 07 Apr 2025 14:49:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEFTVqzWE/SPMnbFDfKIA8GlZV2hPrI0fiHVOYjnOZwAWP58YEjhF8R/jkghKjgd3crklyVkA== X-Received: by 2002:a05:600c:3595:b0:43d:1f1:8cd with SMTP id 5b1f17b1804b1-43ecf9c795emr122524755e9.24.1744062554376; Mon, 07 Apr 2025 14:49:14 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43ec1698081sm143638315e9.17.2025.04.07.14.49.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Apr 2025 14:49:14 -0700 (PDT) Date: Mon, 7 Apr 2025 23:49:12 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 02/12] udp: Make udp_sock_recv() take max number of frames as a parameter Message-ID: <20250407234912.4696f505@elisabeth> In-Reply-To: <20250404101542.3729316-3-david@gibson.dropbear.id.au> References: <20250404101542.3729316-1-david@gibson.dropbear.id.au> <20250404101542.3729316-3-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rUe0TwHMhf-CdKfmiNcjvWxZDpzy1Xhq9aYa4kgPqBo_1744062555 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: SMF23IEYKPGP4VS3QCE6LI6IISJ4TJ3F X-Message-ID-Hash: SMF23IEYKPGP4VS3QCE6LI6IISJ4TJ3F X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 4 Apr 2025 21:15:32 +1100 David Gibson wrote: > Currently udp_sock_recv() decides the maximum number of frames it is > willing to receive based on the mode. However, we have upcoming use cases > where we will have different criteria for how many frames we want with > information that's not naturally available here but is in the caller. So > make the maximum number of frames a parameter. > > Signed-off-by: David Gibson > --- > udp.c | 27 +++++++++++++-------------- > 1 file changed, 13 insertions(+), 14 deletions(-) > > diff --git a/udp.c b/udp.c > index fa6fccdc..8125cfcb 100644 > --- a/udp.c > +++ b/udp.c > @@ -634,22 +634,14 @@ static int udp_sock_errs(const struct ctx *c, union epoll_ref ref) > * @c: Execution context > * @s: Socket to receive from > * @mmh mmsghdr array to receive into > + * @n: Maximum number of datagrams to receive > * > * Return: Number of datagrams received > * > * #syscalls recvmmsg arm:recvmmsg_time64 i686:recvmmsg_time64 > */ > -static int udp_sock_recv(const struct ctx *c, int s, struct mmsghdr *mmh) > +static int udp_sock_recv(const struct ctx *c, int s, struct mmsghdr *mmh, int n) > { > - /* For not entirely clear reasons (data locality?) pasta gets better > - * throughput if we receive tap datagrams one at a atime. For small a atime became... > - * splice datagrams throughput is slightly better if we do batch, but > - * it's slightly worse for large splice datagrams. Since we don't know > - * before we receive whether we'll use tap or splice, always go one at a > - * time for pasta mode. > - */ > - int n = (c->mode == MODE_PASTA ? 1 : UDP_MAX_FRAMES); > - > ASSERT(!c->no_udp); > > n = recvmmsg(s, mmh, n, 0, NULL); > @@ -671,9 +663,10 @@ static void udp_buf_listen_sock_data(const struct ctx *c, union epoll_ref ref, > const struct timespec *now) > { > const socklen_t sasize = sizeof(udp_meta[0].s_in); > - int n, i; > + /* See udp_buf_sock_data() comment */ > + int n = (c->mode == MODE_PASTA ? 1 : UDP_MAX_FRAMES), i; > > - if ((n = udp_sock_recv(c, ref.fd, udp_mh_recv)) <= 0) > + if ((n = udp_sock_recv(c, ref.fd, udp_mh_recv, n)) <= 0) > return; > > /* We divide datagrams into batches based on how we need to send them, > @@ -768,9 +761,15 @@ static bool udp_buf_reply_sock_data(const struct ctx *c, > { > const struct flowside *toside = flowside_at_sidx(tosidx); > uint8_t topif = pif_at_sidx(tosidx); > - int n, i; > + /* For not entirely clear reasons (data locality?) pasta gets better > + * throughput if we receive tap datagrams one at a a time. For small a a time. :) Fixed on merge. -- Stefano