[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200910195014.13ff24e4@carbon>
Date: Thu, 10 Sep 2020 19:50:14 +0200
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
David Ahern <dsahern@...il.com>,
Hangbin Liu <liuhangbin@...il.com>, bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Jiri Benc <jbenc@...hat.com>,
Eelco Chaudron <echaudro@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Lorenzo Bianconi <lorenzo.bianconi@...hat.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>, brouer@...hat.com
Subject: Re: [PATCHv11 bpf-next 2/5] xdp: add a new helper for dev map
multicast support
On Thu, 10 Sep 2020 11:44:50 +0200
Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> Alexei Starovoitov <alexei.starovoitov@...il.com> writes:
>
> > On Wed, Sep 9, 2020 at 8:30 PM David Ahern <dsahern@...il.com> wrote:
> >> >
> >> > I think the packets modification (edit dst mac, add vlan tag, etc) should be
> >> > done on egress, which rely on David's XDP egress support.
> >>
> >> agreed. The DEVMAP used for redirect can have programs attached that
> >> update the packet headers - assuming you want to update them.
> >
> > Then you folks have to submit them as one set.
> > As-is the programmer cannot achieve correct behavior.
>
> The ability to attach a program to devmaps is already there. See:
>
> fbee97feed9b ("bpf: Add support to attach bpf program to a devmap entry")
>
> But now that you mention it, it does appear that this series is skipping
> the hook that will actually run such a program. Didn't realise that was
> in the caller of bq_enqueue() and not inside bq_enqueue() itself...
In the first revisions of Ahern's patchset (before fully integrated in
devmap), this was the case, but it changed in some of the last
revisions. (This also lost the sort-n-bulk effect in the process, that
optimize I-cache). In these earlier revisions it operated on
xdp_frame's. It would have been a lot easier for Hangbin's patch if
the devmap-prog operated on these xdp_frame's.
Maybe we should change the devmap-prog approach, and run this on the
xdp_frame's (in bq_xmit_all() to be precise) . Hangbin's patchset
clearly shows that we need this "layer" between running the xdp_prog and
the devmap-prog.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists