From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 22E105A0272 for ; Wed, 24 Apr 2024 20:31:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713983485; 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=kkeQnLOtD7cm0ppb2mSEwre+RT4wGAn3OsLD9XqDTE8=; b=FuzCb4fGrVxKkGUV90qW1RraOGcr5iBhHxGXlUXl+3EPytRr68Ytc5Doa/EAEe2wEG1tI/ dy1kCG0bPNt2FLm9c6YLqlbiKATI8d6yOWKBbyQFSjSPtApV8P9F2qdiX7czXi9iU90+Cy D/IUh7yqNb7N2A/+gicFnBkH6a2vwYM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-610-qDEXAEHbOuSbzkZe_giC8Q-1; Wed, 24 Apr 2024 14:31:23 -0400 X-MC-Unique: qDEXAEHbOuSbzkZe_giC8Q-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a524b774e39so23232366b.1 for ; Wed, 24 Apr 2024 11:31:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713983482; x=1714588282; 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=kkeQnLOtD7cm0ppb2mSEwre+RT4wGAn3OsLD9XqDTE8=; b=bkKkw5STs99Crot8syFf6R8Ol7ENd2u8kJWrLs35GASikA/NBDPeKj+XEIh5e9XUrW AhqvjXfe/oAfe9Zx1+nH6BoiGmlSYPSNULuPjpbq885wsHMlZWxn5LcIMpmr0zv/oXuQ /EAn2caCxYbnYA1eyTbrnLwO8wlZxHS0LRK/YenFiR7LCTxgj7k5NgD1MwosCCDhijwn MyUbyJsNiGbyCM1suAqd0/VcHvTWGJe9x0plSRmcrNeZsX0ds7l3m2U6EoPkODShULSv YW8E6yI4A0OdmtJ9wULx/w7lDCIp97pt7UdhwyAjqPpTK2DcEIYaOkgjhuRHajr1Jh3E AJ7w== X-Forwarded-Encrypted: i=1; AJvYcCWuMzfz8OpdXJtUdG+7r4yeWiM+AcEfVciO0C9+kqBfwwwyYt5yjth4Hr4wkycXivd6wTzA0OBwV3t84O/5ipH3SUOu X-Gm-Message-State: AOJu0YyMKFhi7+ku2VsuWeTP+yWzMr+JBhR8BuKGzCMXE5cNt/XJDZm6 xr91D9knxO+2YsM2mEvI6j0AJgp9EqulUZrYGsGA6+7Wfc5k4O/AOiV+89dcd8HGUYWje11eDZZ ZHkxm78ZlNrKCVArUHQNDtRTnemEYiuT3eBc3Jzo+CtNuydT09A== X-Received: by 2002:a17:906:34ca:b0:a52:4bde:4999 with SMTP id h10-20020a17090634ca00b00a524bde4999mr427238ejb.31.1713983481981; Wed, 24 Apr 2024 11:31:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHRM0OKtFitRYP/6qvU4DPAArQspNzU8Vbguj8iXcuOt9u5pfVB64O34r8f4wUpK4x1NCY+3Q== X-Received: by 2002:a17:906:34ca:b0:a52:4bde:4999 with SMTP id h10-20020a17090634ca00b00a524bde4999mr427219ejb.31.1713983481436; Wed, 24 Apr 2024 11:31:21 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id kx18-20020a170907775200b00a57e2d39d56sm3180026ejc.223.2024.04.24.11.31.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2024 11:31:20 -0700 (PDT) Date: Wed, 24 Apr 2024 20:30:44 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 1/2] tcp: leverage support of SO_PEEK_OFF socket option when available Message-ID: <20240424203044.2df748d7@elisabeth> In-Reply-To: References: <20240420191920.104876-1-jmaloy@redhat.com> <20240420191920.104876-2-jmaloy@redhat.com> <20240423195010.2b4d5c13@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: Z23GGMVT2AZWMFZLW2HUTZYXX7ZSUBSL X-Message-ID-Hash: Z23GGMVT2AZWMFZLW2HUTZYXX7ZSUBSL 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: Jon Maloy , passt-dev@passt.top, lvivier@redhat.com, dgibson@redhat.com 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 Wed, 24 Apr 2024 10:48:05 +1000 David Gibson wrote: > On Tue, Apr 23, 2024 at 07:50:10PM +0200, Stefano Brivio wrote: > > On Sat, 20 Apr 2024 15:19:19 -0400 > > Jon Maloy wrote: > [snip] > > > + set_peek_offset(s, 0); > > > > Do we really need to initialise it to zero on a new connection? Extra > > system calls on this path matter for latency of connection > > establishment. > > Sort of, yes: we need to enable the SO_PEEK_OFF behaviour by setting > it to 0, rather than the default -1. By the way of which, this is not documented at this point -- a man page patch (linux-man and linux-api lists) would be nice. > We could lazily enable it, but > we'd need either to a) do it later in the handshake (maybe when we set > ESTABLISHED), but we'd need to be careful it is always set before the > first MSG_PEEK I was actually thinking that we could set it only as we receive data (not every connection will receive data), and keep this out of the handshake (which we want to keep "faster", I think). And setting it as we mark a connection as ESTABLISHED should have the same effect on latency as setting it on a new connection -- that's not really lazy. So, actually: > or b) keep track of whether it's set on a per-socket > basis (this would have the advantage of robustness if we ever > encountered a kernel that weirdly allows it for some but not all TCP > sockets). ...this could be done as we receive data in tcp_data_from_sock(), with a new flag in tcp_tap_conn::flags, to avoid adding latency to the handshake. It also looks more robust to me, and done/checked in a single place where we need it. We have just three bits left there which isn't great, but if we need to save one at a later point, we can drop this new flag easily. -- Stefano