From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Jon Maloy <jmaloy@redhat.com>,
passt-dev@passt.top, lvivier@redhat.com, dgibson@redhat.com
Subject: Re: [PATCH] tcp: probe for SO_PEEK_OFF both in tcpv4 and tcp6
Date: Mon, 22 Jul 2024 10:55:58 +1000 [thread overview]
Message-ID: <Zp2uHucMrtn6ZDom@zatzit> (raw)
In-Reply-To: <20240721112118.2adcc6cf@elisabeth>
[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]
On Sun, Jul 21, 2024 at 11:21:18AM +0200, Stefano Brivio wrote:
> On Sat, 20 Jul 2024 10:46:07 -0400
> Jon Maloy <jmaloy@redhat.com> wrote:
>
> > My first approach to this was to condition the use of SO_PEEK_OFF with
> > tcpv4, e.g., basically
> > a test like if (v4 && peek_offset_cap) {...} everywhere, but then I made
> > an interesting discovery.
> >
> > It turns out that, unless the ´-4' option is explicitly given on the
> > command line, all sockets are
> > v6, even those that are later used as v4 sockets.
>
> Not necessarily: if IPv6 support is disabled for other reasons, such as
> the fact that we didn't find any routable IPv6 address, sockets will
> also be IPv4-only. See tcp_sock_init().
Also, if your forwarding options give explicit IPv4 addresses (or even
"0.0.0.0") you'll get IPv4 sockets...
> > So, the set_peek_off()
> > call failed even
> > for supposedly v4 sockets.
> >
> > I checked this by adding a printout to the tcp_listen_handler(), and
> > noticed that all returns from
> > the accept4() call goes into the AF_INET6 branch, even when the client
> > (iperf3) call is using an IPv4 address.
> > During traffic, the very same socket is marked as v4 in the tcp_tap_conn
> > structure, and this seems to
> > have worked just fine until I added the set_peek_offset call().
> >
> > I believe this is an issue that has been introduced during the last
> > months, since I didn't start
> > using the ´-4' option consistently until some months ago, and then it
> > worked.
>
> That's not actually an issue, it's intended, see commit 8e914238b6de
> ("tcp: Use dual stack sockets for port forwarding when possible").
..because this is exactly the reason. We're using dual stack sockets
to reduce the amount of kernel memory we consume with many forwards.
> Could it be that you enabled IPv6 on your setup meanwhile, and that's
> why you see this now? I think I tested your changes on an isolated
> IPv4-only setup, as I didn't run a kernel version with SO_PEEK_OFF
> support at the time.
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-07-22 0:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-20 13:54 [PATCH] tcp: probe for SO_PEEK_OFF both in tcpv4 and tcp6 Jon Maloy
2024-07-20 14:46 ` Jon Maloy
2024-07-21 9:21 ` Stefano Brivio
2024-07-22 0:55 ` David Gibson [this message]
2024-07-21 9:20 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zp2uHucMrtn6ZDom@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=dgibson@redhat.com \
--cc=jmaloy@redhat.com \
--cc=lvivier@redhat.com \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).