From: Thiago Macieira <thiago.macieira@intel.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Matthew Dawson <matthew@mjdsystems.ca>,
Paolo Abeni <pabeni@redhat.com>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net] datagram: When peeking datagrams with offset < 0 don't skip empty skbs
Date: Mon, 14 Aug 2017 11:58:30 -0700 [thread overview]
Message-ID: <1756525.aGoekHffaC@tjmaciei-mobl1> (raw)
In-Reply-To: <CAF=yD-L_-XrrPTfqYKGShqYdadER_Qo9_0CoAYE0r=NrircDXA@mail.gmail.com>
On Monday, 14 August 2017 11:46:42 PDT Willem de Bruijn wrote:
> > By the way, what were the usecases for the peek offset feature?
>
> The idea was to be able to peek at application headers of upper
> layer protocols and multiplex messages among threads. It proved
> so complex even for UDP that we did not attempt the same feature
> for TCP. Also, KCM implements demultiplexing using eBPF today.
Interesting, but how would userspace coordinate like that? Suppose multiple
threads are woken up by a datagram being received, they peek at a certain
offset shared among them all to see which one reads. Suppose that thread is
slow or blocked and, while it's getting its act together, another datagram
arrives.
Because of that, the other threads can't disable their polling. They will
continually be woken up by the kernel if they go back to poll/select. Even
with epoll, there's no new edge trigger since event is already at level.
How will they avoid busy-waiting? And won't this secondary coordination
obviate the need for offset peeking?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
next prev parent reply other threads:[~2017-08-14 18:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 5:52 [PATCH net] datagram: When peeking datagrams with offset < 0 don't skip empty skbs Matthew Dawson
2017-08-14 9:27 ` Paolo Abeni
2017-08-14 14:05 ` Matthew Dawson
2017-08-14 15:03 ` Willem de Bruijn
2017-08-14 15:31 ` Paolo Abeni
2017-08-15 1:35 ` Willem de Bruijn
2017-08-15 15:40 ` Paolo Abeni
2017-08-15 16:45 ` Willem de Bruijn
2017-08-15 17:00 ` Willem de Bruijn
2017-08-16 9:28 ` Paolo Abeni
2017-08-16 15:18 ` Willem de Bruijn
2017-08-16 20:20 ` Paolo Abeni
2017-08-16 23:27 ` Willem de Bruijn
2017-08-16 23:40 ` Willem de Bruijn
2017-08-16 23:55 ` Thiago Macieira
2017-08-17 0:10 ` Willem de Bruijn
2017-08-17 9:15 ` David Laight
2017-08-17 14:37 ` Willem de Bruijn
2017-08-17 15:47 ` Matthew Dawson
2017-08-17 16:45 ` Willem de Bruijn
2017-08-15 18:17 ` Paolo Abeni
2017-08-14 16:06 ` Thiago Macieira
2017-08-14 16:33 ` Willem de Bruijn
2017-08-14 17:02 ` Thiago Macieira
2017-08-14 18:25 ` Willem de Bruijn
2017-08-14 18:33 ` Thiago Macieira
2017-08-14 18:46 ` Willem de Bruijn
2017-08-14 18:58 ` Thiago Macieira [this message]
2017-08-14 19:03 ` Willem de Bruijn
2017-08-14 19:15 ` Thiago Macieira
2017-08-14 19:39 ` Willem de Bruijn
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=1756525.aGoekHffaC@tjmaciei-mobl1 \
--to=thiago.macieira@intel.com \
--cc=matthew@mjdsystems.ca \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemdebruijn.kernel@gmail.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox