Netdev List
 help / color / mirror / Atom feed
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 12:15:27 -0700	[thread overview]
Message-ID: <4013878.dizogNlyrN@tjmaciei-mobl1> (raw)
In-Reply-To: <CAF=yD-K4HgOhMMT0tWycZgcqhU5OACQk_roPQEeRems1_Azhgw@mail.gmail.com>

On Monday, 14 August 2017 12:03:16 PDT Willem de Bruijn wrote:
> On Mon, Aug 14, 2017 at 2:58 PM, Thiago Macieira
> 
> <thiago.macieira@intel.com> wrote:
> > 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
> 
> This assumes a separate listener thread and worker threadpool.

The listener thread still needs to synchronise with the worker that got 
activated and wait for it to recv from the socket before the listener thread 
can go back to poll().

If we are really talking about threads in the same process, it might be easier 
for the listener to just read the datagram anyway and pass it on to the 
worker. That way, it can proceed immediately to the next datagram and not have 
to wait for the possibly slow worker.

If it is a separate process, then I don't see another way and this might be 
necessary.

By the way, what does recv with MSG_PEEK | MSG_TRUNC return? Is it the full 
datagram's size or is it the size minus the peek offset?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

  reply	other threads:[~2017-08-14 19:15 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
2017-08-14 19:03                     ` Willem de Bruijn
2017-08-14 19:15                       ` Thiago Macieira [this message]
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=4013878.dizogNlyrN@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