From: Bobby Eshleman <bobbyeshleman@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Stanislav Fomichev <sdf@fomichev.me>,
Mina Almasry <almasrymina@google.com>, David Wei <dw@davidwei.uk>,
Bobby Eshleman <bobbyeshleman@meta.com>
Subject: Re: [PATCH net-next] tcp: devmem: only pre-allocate tokens the receiver can consume
Date: Fri, 4 Sep 2026 15:44:28 -0700 [thread overview]
Message-ID: <aptJzJ5VtKsb06lo@devvm29614.prn0.facebook.com> (raw)
In-Reply-To: <20260904151146.602c61a4@kernel.org>
On Fri, Sep 04, 2026 at 03:11:46PM -0700, Jakub Kicinski wrote:
> On Wed, 02 Sep 2026 15:24:19 -0700 Bobby Eshleman wrote:
> > Testing on a CX7 w/ GRO and a steady sendmsg() flow of 1MB per send, we
> > see a typical RX-side skb touch upwards of ~32KB. With a 4KB recvmsg
> > size, probing shows that ~75% of the allocated tokens are not used.
>
> 4kB seems unreasonably small. Is there a real life reason to use such
> a small buffer / read length?
I have workloads now that deal w/ varying sized tensors (<32K up to
100MB), and data send/recv is done per-tensor (with the size/metadata
sent over a control path via normal TCP). Right now the application just
safe guards against the small tensor case by receiving anything under
32K via regular TCP, and anything over via TCP dm. Figured might as well
try to lift the restriction. To your point though, I don't expect a
consistent flow of <32K to be the common case. Could be something we
shelve until it really becomes painful.
Best,
Bobby
prev parent reply other threads:[~2026-09-04 22:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 22:24 Bobby Eshleman
2026-09-04 22:11 ` Jakub Kicinski
2026-09-04 22:44 ` Bobby Eshleman [this message]
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=aptJzJ5VtKsb06lo@devvm29614.prn0.facebook.com \
--to=bobbyeshleman@gmail.com \
--cc=almasrymina@google.com \
--cc=bobbyeshleman@meta.com \
--cc=davem@davemloft.net \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®