All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: john.fastabend@gmail.com
Cc: ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org,
	davejwatson@fb.com
Subject: Re: [bpf-next PATCH 05/16] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data
Date: Tue, 06 Mar 2018 01:42:42 -0500 (EST)	[thread overview]
Message-ID: <20180306.014242.2009864411917823422.davem@davemloft.net> (raw)
In-Reply-To: <9c82ae47-59a1-f140-9d10-31e691fb3c51@gmail.com>

From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 5 Mar 2018 22:22:21 -0800

> All I meant by this is if an application uses sendfile() call
> there is no good way to know when/if the kernel side will copy or
> xmit the  data. So a reliable user space application will need to
> only modify the data if it "knows" there are no outstanding sends
> in-flight. So if we assume applications follow this then it
> is OK to avoid the copy. Of course this is not good enough for
> security, but for monitoring/statistics (my use case 1 it works).

For an application implementing a networking file system, it's pretty
legitimate for file contents to change before the page gets DMA's to
the networking card.

And that's perfectly fine, and we everything such that this will work
properly.

The card checksums what ends up being DMA'd so nothing from the
networking side is broken.

So this assumption you mention really does not hold.

There needs to be some feedback from the BPF program that parses the
packet.  This way it can say, "I need at least X more bytes before I
can generate a verdict".  And you keep copying more and more bytes
into a linear buffer and calling the parser over and over until it can
generate a full verdict or you run out of networking data.

  reply	other threads:[~2018-03-06  6:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 19:50 [bpf-next PATCH 00/16] bpf,sockmap: sendmsg/sendfile ULP John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 01/16] sock: make static tls function alloc_sg generic sock helper John Fastabend
2018-03-05 21:32   ` David Miller
2018-03-05 19:51 ` [bpf-next PATCH 02/16] sockmap: convert refcnt to an atomic refcnt John Fastabend
2018-03-05 21:34   ` David Miller
2018-03-05 19:51 ` [bpf-next PATCH 03/16] net: do_tcp_sendpages flag to avoid SKBTX_SHARED_FRAG John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 04/16] net: generalize sk_alloc_sg to work with scatterlist rings John Fastabend
2018-03-05 21:35   ` David Miller
2018-03-05 19:51 ` [bpf-next PATCH 05/16] bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data John Fastabend
2018-03-05 21:40   ` David Miller
2018-03-05 22:53     ` John Fastabend
2018-03-06  5:42       ` David Miller
2018-03-06  6:22         ` John Fastabend
2018-03-06  6:42           ` David Miller [this message]
2018-03-06  7:06             ` John Fastabend
2018-03-06 15:47               ` David Miller
2018-03-06 18:18                 ` John Fastabend
2018-03-07  3:25                   ` John Fastabend
2018-03-07  4:41                     ` David Miller
2018-03-07 13:03                     ` Daniel Borkmann
2018-03-05 19:51 ` [bpf-next PATCH 06/16] bpf: sockmap, add bpf_msg_apply_bytes() helper John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 07/16] bpf: sockmap, add msg_cork_bytes() helper John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 08/16] bpf: add map tests for BPF_PROG_TYPE_SK_MSG John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 09/16] bpf: add verifier " John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 10/16] bpf: sockmap sample, add option to attach SK_MSG program John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 11/16] bpf: sockmap sample, add sendfile test John Fastabend
2018-03-05 19:51 ` [bpf-next PATCH 12/16] bpf: sockmap sample, add data verification option John Fastabend
2018-03-05 19:52 ` [bpf-next PATCH 13/16] bpf: sockmap, add sample option to test apply_bytes helper John Fastabend
2018-03-05 19:52 ` [bpf-next PATCH 14/16] bpf: sockmap sample support for bpf_msg_cork_bytes() John Fastabend
2018-03-05 19:52 ` [bpf-next PATCH 15/16] sockmap: add SK_DROP tests John Fastabend
2018-03-05 19:52 ` [bpf-next PATCH 16/16] bpf: sockmap test script John Fastabend

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=20180306.014242.2009864411917823422.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davejwatson@fb.com \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.