All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Andy Gospodarek <andy@greyhouse.net>,
	Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Daniel Borkmann <borkmann@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Alexei Starovoitov <ast@fb.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xdp-newbies@vger.kernel.org" <xdp-newbies@vger.kernel.org>,
	John Fastabend <john.fastabend@gmail.com>
Subject: Re: XDP question: best API for returning/setting egress port?
Date: Wed, 19 Apr 2017 23:42:30 +0200	[thread overview]
Message-ID: <58F7D9C6.5040707@iogearbox.net> (raw)
In-Reply-To: <20170419200259.GK4730@C02RW35GFVH8.dhcp.broadcom.net>

On 04/19/2017 10:02 PM, Andy Gospodarek wrote:
> On Tue, Apr 18, 2017 at 09:58:56PM +0200, Jesper Dangaard Brouer wrote:
>>
>> As I argued in NetConf presentation[1] (from slide #9) we need a port
>> mapping table (instead of using ifindex'es).  Both for supporting
>> other "port" types than net_devices (think sockets), and for
>> sandboxing what XDP can bypass.
>>
>> I want to create a new XDP action called XDP_REDIRECT, that instruct
>> XDP to send the xdp_buff to another "port" (get translated into a
>> net_device, or something else depending on internal port type).
>>
>> Looking at the userspace/eBPF interface, I'm wondering what is the
>> best API for "returning" this port number from eBPF?
>>
>> The options I see is:
>>
>> 1) Split-up the u32 action code, and e.g let the high-16-bit be the
>>     port number and lower-16bit the (existing) action verdict.
>>
>>   Pros: Simple API
>>   Cons: Number of ports limited to 64K
>
> Practically speaking this may be seem reserving 64k for the port number
> might be enough space, but I would also like to see a new return option
> for flags so I start to get concerned about space.  Daniel also
> hightlights the fact that encoding the port in the action may does not
> leave room for flags and could get confusing.
>
> One unfortunate side-effect of dropping or transmitting frames with XDP
> is that we lose the opportunity to statistically sample in netfilter
> since the frames were dropped so early and I'd like to bring that back
> with a call to parse flags and possibly call psample_sample_packet()
> after the xdp action.  Packet sampling cannot simply be an action
> since there are times when a frame should be dropped but should also be
> sampled, so it seems logical to add this as a flag.

Hmm, you can do that already today with bpf_xdp_event_output() helper
and the program decides when to sample and what custom meta data to
prepend along with the (partial or full) xdp packet, see also [1], slide
11 for the "XDP dump" part.

No need to change drivers for this, psample_sample_packet() would also
be slower.

   [1] http://netdevconf.org/2.1/slides/apr6/zhou-netdev-xdp-2017.pdf

  reply	other threads:[~2017-04-19 21:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 19:58 XDP question: best API for returning/setting egress port? Jesper Dangaard Brouer
2017-04-18 20:54 ` John Fastabend
2017-04-19 12:00   ` Jesper Dangaard Brouer
2017-04-19 12:33     ` Daniel Borkmann
2017-04-19 15:24       ` Jesper Dangaard Brouer
2017-04-19 12:25 ` Hannes Frederic Sowa
2017-04-19 20:02 ` Andy Gospodarek
2017-04-19 21:42   ` Daniel Borkmann [this message]
2017-04-20 17:12     ` Andy Gospodarek
2017-04-19 22:51   ` Daniel Borkmann
2017-04-20  2:56     ` xdp_redirect ifindex vs port. Was: " Alexei Starovoitov
2017-04-20  4:38       ` John Fastabend
2017-04-20  4:58         ` Alexei Starovoitov
2017-04-20  5:14           ` John Fastabend
2017-04-20  6:10       ` Jesper Dangaard Brouer
2017-04-20 17:10         ` Alexei Starovoitov
2017-04-25  9:34           ` Jesper Dangaard Brouer
2017-04-26  0:26             ` Alexei Starovoitov
2017-04-26  3:07               ` John Fastabend
2017-04-26  9:11                 ` Jesper Dangaard Brouer
2017-04-26 16:35                   ` John Fastabend
2017-04-26 17:58                     ` Alexei Starovoitov
2017-04-26 20:55                       ` Andy Gospodarek
2017-04-27  8:41                         ` Jesper Dangaard Brouer
2017-04-27 23:31                           ` Alexei Starovoitov
2017-04-28  5:06                             ` John Fastabend
2017-04-28  5:30                               ` Alexei Starovoitov
2017-04-28 19:43                                 ` Hannes Frederic Sowa
2017-04-30  1:35                                   ` Alexei Starovoitov
2017-04-28 10:58                             ` Jesper Dangaard Brouer
2017-04-30  1:04                               ` Alexei Starovoitov
2017-04-30 22:55                                 ` John Fastabend
2017-04-20  6:39     ` XDP question: " Jesper Dangaard Brouer
2017-04-20  4:43   ` 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=58F7D9C6.5040707@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=ast@fb.com \
    --cc=borkmann@iogearbox.net \
    --cc=brouer@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=xdp-newbies@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.