All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	Jiri Benc <jbenc@redhat.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Eelco Chaudron <echaudro@redhat.com>,
	ast@kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
	Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	David Ahern <dsahern@gmail.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	bjorn@kernel.org
Subject: Re: [PATCHv2 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support
Date: Thu, 18 Mar 2021 15:19:47 +0100	[thread overview]
Message-ID: <875z1oczng.fsf@toke.dk> (raw)
In-Reply-To: <20210318035200.GB2900@Leo-laptop-t470s>

Hangbin Liu <liuhangbin@gmail.com> writes:

> On Wed, Mar 17, 2021 at 01:03:02PM +0100, Toke Høiland-Jørgensen wrote:
>> FYI, this no longer applies to bpf-next due to Björn's refactor in
>> commit: ee75aef23afe ("bpf, xdp: Restructure redirect actions")
>
> Thanks Toke, I need to see how to get the map via map_id, does
> bpf_map_get_curr_or_next() works? Should I call bpf_map_put() after
> using?

I would expect that to be terrible for performance; I think it would be
better to just add back the map pointer into struct bpf_redirect_info.
If you only set the map pointer when the multicast flag is set, you can
just check that pointer to disambiguate between when you need to call
dev_map_enqueue() and dev_map_enqueue_multi(), in which case you don't
need to add back the flags member...

-Toke


  parent reply	other threads:[~2021-03-18 14:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 10:13 [PATCHv2 bpf-next 0/4] xdp: extend xdp_redirect_map with broadcast support Hangbin Liu
2021-03-09 10:13 ` [PATCHv2 bpf-next 1/4] bpf: run devmap xdp_prog on flush instead of bulk enqueue Hangbin Liu
2021-03-09 10:13 ` [PATCHv2 bpf-next 2/4] xdp: extend xdp_redirect_map with broadcast support Hangbin Liu
2021-03-17 12:03   ` Toke Høiland-Jørgensen
2021-03-18  3:52     ` Hangbin Liu
2021-03-18  8:20       ` Björn Töpel
2021-03-18 14:19       ` Toke Høiland-Jørgensen [this message]
2021-03-23  2:49         ` Hangbin Liu
2021-03-23 10:15           ` Toke Høiland-Jørgensen
2021-03-09 10:13 ` [PATCHv2 bpf-next 3/4] sample/bpf: add xdp_redirect_map_multi for redirect_map broadcast test Hangbin Liu
2021-03-09 10:13 ` [PATCHv2 bpf-next 4/4] selftests/bpf: add xdp_redirect_multi test Hangbin Liu

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=875z1oczng.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=echaudro@redhat.com \
    --cc=jbenc@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=liuhangbin@gmail.com \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=maciej.fijalkowski@intel.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.