From: David Laight <David.Laight@ACULAB.COM>
To: 'Victor Stewart' <v@nametag.social>,
Pavel Begunkov <asml.silence@gmail.com>
Cc: io-uring <io-uring@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Subject: RE: io_uring: BPF controlled I/O
Date: Mon, 14 Jun 2021 07:54:00 +0000 [thread overview]
Message-ID: <2d4e188665c5425296f2da0e96c744af@AcuMS.aculab.com> (raw)
In-Reply-To: <CAM1kxwjHrf74u5OLB=acP2fBy+cPG4NNxa-51O35caY4VKdkkg@mail.gmail.com>
From: Victor Stewart
> Sent: 07 June 2021 19:51
...
> coincidentally i'm tossing around in my mind at the moment an idea for
> offloading
> the PING/PONG of a QUIC server/client into the kernel via eBPF.
>
> problem being, being that QUIC is userspace run transport and that NAT-ed UDP
> mappings can't be expected to stay open longer than 30 seconds, QUIC
> applications
> bare a large cost of context switching wake-up to conduct connection lifetime
> maintenance... especially when managing a large number of mostly idle long lived
> connections. so offloading this maintenance service into the kernel
> would be a great
> efficiency boon.
>
> the main impediment is that access to the kernel crypto libraries
> isn't currently possible
> from eBPF. that said, connection wide crypto offload into the NIC is a
> frequently mentioned
> subject in QUIC circles, so one could argue better to allocate the
> time to NIC crypto offload
> and then simply conduct this PING/PONG offload in plain text.
Hmmmm... a good example of how not to type emails.
Thought, does the UDP tx needed to keep the NAT tables active
need to be encrypted?
A single byte UDP packet would do the trick.
You just need something the remote system is designed to ignore.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2021-06-14 7:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-05 9:08 io_uring: BPF controlled I/O Pavel Begunkov
2021-06-05 9:16 ` [LSF/MM/BPF TOPIC] " Pavel Begunkov
2021-06-07 18:51 ` Victor Stewart
2021-06-10 9:09 ` Pavel Begunkov
2021-06-14 7:54 ` David Laight [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=2d4e188665c5425296f2da0e96c744af@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=v@nametag.social \
/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;
as well as URLs for NNTP newsgroup(s).