Martin KaFai Lau writes:
> On Thu, Apr 15, 2021 at 09:53:17PM +0800, Hangbin Liu wrote:
>> From: Jesper Dangaard Brouer
>>
>> This changes the devmap XDP program support to run the program when the
>> bulk queue is flushed instead of before the frame is enqueued. This has
>> a couple of benefit
type, but not back to PACKET_HOST. So
>> this works, just a bit confusing :)
>
> Indeed. I considered changing eth_type_trans() to always reset
> pkt_type, but I didn't want to take the risk for any side effects.
Hmm, yeah, it does seem there are quite a few call sites to audit if you
were to change the behaviour. I guess we'll have to live with the slight
confusion, then :)
-Toke
Given the above:
Acked-by: Toke Høiland-Jørgensen
"Paul E. McKenney" writes:
> On Mon, Apr 19, 2021 at 11:21:41PM +0200, Toke Høiland-Jørgensen wrote:
>> "Paul E. McKenney" writes:
>>
>> > On Mon, Apr 19, 2021 at 08:12:27PM +0200, Toke Høiland-Jørgensen wrote:
>> >> "Paul E. McKenne
Daniel Borkmann writes:
> On 4/19/21 2:18 PM, Kumar Kartikeya Dwivedi wrote:
>> This adds functions that wrap the netlink API used for adding,
>> manipulating, and removing traffic control filters. These functions
>> operate directly on the loaded prog's fd, and return a handle to the
>> filter u
"Paul E. McKenney" writes:
> On Mon, Apr 19, 2021 at 08:12:27PM +0200, Toke Høiland-Jørgensen wrote:
>> "Paul E. McKenney" writes:
>>
>> > On Sat, Apr 17, 2021 at 02:27:19PM +0200, Toke Høiland-Jørgensen wrote:
>> >> "Paul E. McKenne
"Paul E. McKenney" writes:
> On Sat, Apr 17, 2021 at 02:27:19PM +0200, Toke Høiland-Jørgensen wrote:
>> "Paul E. McKenney" writes:
>>
>> > On Fri, Apr 16, 2021 at 11:22:52AM -0700, Martin KaFai Lau wrote:
>> >> On Fri, Apr 16, 2021 at 03
Martin Willi writes:
> If a generic XDP program changes the destination MAC address from/to
> multicast/broadcast, the skb->pkt_type is updated to properly handle
> the packet when passed up the stack. When changing the MAC from/to
> the NICs MAC, PACKET_HOST/OTHERHOST is not updated, though, mak
gt;> > > On Thu, Apr 15, 2021 at 10:29:40PM +0200, Toke Høiland-Jørgensen wrote:
>> > > > Jesper Dangaard Brouer writes:
>> > > >
>> > > > > On Thu, 15 Apr 2021 10:35:51 -0700
>> > > > > Martin KaFai Lau wrote:
>>
Paolo Abeni writes:
> On Fri, 2021-04-16 at 17:29 +0200, Toke Høiland-Jørgensen wrote:
>> Paolo Abeni writes:
>>
>> > On Fri, 2021-04-09 at 16:58 +0200, Toke Høiland-Jørgensen wrote:
>> > > Paolo Abeni writes:
>> > >
>> > > >
ck in veth_xdp_xmit() to also look at the new NAPI pointer,
so let's fix that.
Fixes: 6788fa154546 ("veth: allow enabling NAPI even without XDP")
Signed-off-by: Toke Høiland-Jørgensen
---
drivers/net/veth.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/
Paolo Abeni writes:
> On Fri, 2021-04-09 at 16:58 +0200, Toke Høiland-Jørgensen wrote:
>> Paolo Abeni writes:
>>
>> > Currently the veth device has the GRO feature bit set, even if
>> > no GRO aggregation is possible with the default configuration,
>>
Jesper Dangaard Brouer writes:
> On Thu, 15 Apr 2021 17:39:13 -0700
> Martin KaFai Lau wrote:
>
>> On Thu, Apr 15, 2021 at 10:29:40PM +0200, Toke Høiland-Jørgensen wrote:
>> > Jesper Dangaard Brouer writes:
>> >
>> > > On Thu, 15 Apr 2021
Martin KaFai Lau writes:
> On Thu, Apr 15, 2021 at 10:29:40PM +0200, Toke Høiland-Jørgensen wrote:
>> Jesper Dangaard Brouer writes:
>>
>> > On Thu, 15 Apr 2021 10:35:51 -0700
>> > Martin KaFai Lau wrote:
>> >
>> >> On Thu, Apr 15,
gt;>>> On 4/15/21 1:19 AM, Andrii Nakryiko wrote:
>>>>>> On Wed, Apr 14, 2021 at 3:51 PM Toke Høiland-Jørgensen
>>>>>> wrote:
>>>>>>> Andrii Nakryiko writes:
>>>>>>>> On Wed, Apr 14, 2021 at 3:58 AM To
Jesper Dangaard Brouer writes:
> On Thu, 15 Apr 2021 10:35:51 -0700
> Martin KaFai Lau wrote:
>
>> On Thu, Apr 15, 2021 at 11:22:19AM +0200, Toke Høiland-Jørgensen wrote:
>> > Hangbin Liu writes:
>> >
>> > > On Wed, Apr 14, 202
Andrii Nakryiko writes:
> On Wed, Apr 14, 2021 at 3:51 PM Toke Høiland-Jørgensen
> wrote:
>>
>> Andrii Nakryiko writes:
>>
>> > On Wed, Apr 14, 2021 at 3:58 AM Toke Høiland-Jørgensen
>> > wrote:
>> >>
>> >> Andrii Nakryiko
Hangbin Liu writes:
> On Wed, Apr 14, 2021 at 05:23:50PM -0700, Martin KaFai Lau wrote:
>> On Wed, Apr 14, 2021 at 08:26:08PM +0800, Hangbin Liu wrote:
>> [ ... ]
>>
>> > +static __always_inline int __bpf_xdp_redirect_map(struct bpf_map *map,
>> > u32 ifindex,
>> > +
Hangbin Liu writes:
> On Wed, Apr 14, 2021 at 05:17:11PM -0700, Martin KaFai Lau wrote:
>> > static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags)
>> > {
>> >struct net_device *dev = bq->dev;
>> > - int sent = 0, err = 0;
>> > + int sent = 0, drops = 0, err = 0;
>> > + unsign
Andrii Nakryiko writes:
> On Wed, Apr 14, 2021 at 3:58 AM Toke Høiland-Jørgensen
> wrote:
>>
>> Andrii Nakryiko writes:
>>
>> > On Tue, Apr 6, 2021 at 3:06 AM Toke Høiland-Jørgensen
>> > wrote:
>> >>
>> >> Andrii Nakr
ort.
>
> With BPF_F_BROADCAST the packet will be broadcasted to all the interfaces
> in the map. with BPF_F_EXCLUDE_INGRESS the ingress interface will be
> excluded when do broadcasting.
Alright, I'm out of things to complain about - thanks for sticking with
it! :)
For the series:
Acked-by: Toke Høiland-Jørgensen
Hangbin Liu writes:
> This patch adds two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to
> extend xdp_redirect_map for broadcast support.
>
> With BPF_F_BROADCAST the packet will be broadcasted to all the interfaces
> in the map. with BPF_F_EXCLUDE_INGRESS the ingress interface will be
> excl
Andrii Nakryiko writes:
> On Tue, Apr 6, 2021 at 3:06 AM Toke Høiland-Jørgensen wrote:
>>
>> Andrii Nakryiko writes:
>>
>> > On Sat, Apr 3, 2021 at 10:47 AM Alexei Starovoitov
>> > wrote:
>> >>
>> >> On Sat, Apr 03, 2021 at 12:38
to redirect UDP frames from
> ixgbe driver to a cpumap entry and then to the networking stack.
> UDP frames are generated using pkt_gen.
>
> $xdp_redirect_cpu --cpu --progname xdp_cpu_map0 --dev
>
> bpf-next: ~2.2Mpps
> bpf-next + cpumap skb-list: ~3.15Mpps
Nice! :)
Acked-by: Toke Høiland-Jørgensen
Hangbin Liu writes:
> This patch adds two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to
> extend xdp_redirect_map for broadcast support.
>
> With BPF_F_BROADCAST the packet will be broadcasted to all the interfaces
> in the map. with BPF_F_EXCLUDE_INGRESS the ingress interface will be
> excl
Paolo Abeni writes:
> hello,
>
> On Fri, 2021-04-09 at 16:57 +0200, Toke Høiland-Jørgensen wrote:
>> Paolo Abeni writes:
>>
>> > After the previous patch, when enabling GRO, locally generated
>> > TCP traffic experiences some measurable overhead, as it tr
Paolo Abeni writes:
> Currently the veth device has the GRO feature bit set, even if
> no GRO aggregation is possible with the default configuration,
> as the veth device does not hook into the GRO engine.
>
> Flipping the GRO feature bit from user-space is a no-op, unless
> XDP is enabled. In su
Paolo Abeni writes:
> After the previous patch, when enabling GRO, locally generated
> TCP traffic experiences some measurable overhead, as it traverses
> the GRO engine without any chance of aggregation.
>
> This change refine the NAPI receive path admission test, to avoid
> unnecessary GRO over
John Fastabend writes:
> Toke Høiland-Jørgensen wrote:
>> John Fastabend writes:
>>
>> > Toke Høiland-Jørgensen wrote:
>> >> Hangbin Liu writes:
>> >>
>> >> > On Mon, Apr 05, 2021 at 05:24:48PM -0700, John Fastabend wrote:
John Fastabend writes:
> Toke Høiland-Jørgensen wrote:
>> Hangbin Liu writes:
>>
>> > On Mon, Apr 05, 2021 at 05:24:48PM -0700, John Fastabend wrote:
>> >> Hangbin Liu wrote:
>> >> > This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_
Jiri Olsa writes:
> Currently we don't allow re-attaching of trampolines. Once
> it's detached, it can't be re-attach even when the program
> is still loaded.
>
> Adding the possibility to re-attach the loaded tracing and
> lsm programs.
>
> Signed-off
Vladimir Oltean writes:
> On Sat, Apr 03, 2021 at 01:07:29PM +0200, Toke Høiland-Jørgensen wrote:
>> Vladimir Oltean writes:
>>
>> > On Thu, Apr 01, 2021 at 10:38:21PM +0300, Vladimir Oltean wrote:
>> >> On Thu, Apr 01, 2021 at 08:01:42PM +0200, Toke Høila
Hangbin Liu writes:
> This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to extend
> xdp_redirect_map for broadcast support.
>
> Keep the general data path in net/core/filter.c and the native data
> path in kernel/bpf/devmap.c so we can use direct calls to get better
> performace.
Hangbin Liu writes:
> On Mon, Apr 05, 2021 at 05:24:48PM -0700, John Fastabend wrote:
>> Hangbin Liu wrote:
>> > This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to
>> > extend
>> > xdp_redirect_map for broadcast support.
>> >
>> > Keep the general data path in net/core/filter
Andrii Nakryiko writes:
> On Sat, Apr 3, 2021 at 10:47 AM Alexei Starovoitov
> wrote:
>>
>> On Sat, Apr 03, 2021 at 12:38:06AM +0530, Kumar Kartikeya Dwivedi wrote:
>> > On Sat, Apr 03, 2021 at 12:02:14AM IST, Alexei Starovoitov wrote:
>> > > On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwived
Jiri Olsa writes:
> On Sat, Apr 03, 2021 at 11:21:55AM -0700, Alexei Starovoitov wrote:
>> On Sat, Apr 03, 2021 at 01:24:12PM +0200, Toke Høiland-Jørgensen wrote:
>> > > if (!prog->aux->dst_trampoline && !tgt_prog) {
>> > > -
really consider this case when I added the original
disallow. But don't see why not, so (with one nit below):
Acked-by: Toke Høiland-Jørgensen
> Signed-off-by: Jiri Olsa
> ---
> kernel/bpf/syscall.c| 25 +++--
> kernel/bpf/trampoline.c | 2 +-
> 2 file
Vladimir Oltean writes:
> On Thu, Apr 01, 2021 at 10:38:21PM +0300, Vladimir Oltean wrote:
>> On Thu, Apr 01, 2021 at 08:01:42PM +0200, Toke Høiland-Jørgensen wrote:
>> > Vladimir Oltean writes:
>> >
>> > > On Thu, Apr 01, 2021 at 01:39:0
Vladimir Oltean writes:
> On Thu, Apr 01, 2021 at 01:26:02PM +0200, Toke Høiland-Jørgensen wrote:
>> > +int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
>> > + struct xdp_frame **frames, u32 flags)
>> > +{
>> > + struct enetc_tx_sw
Vladimir Oltean writes:
> On Thu, Apr 01, 2021 at 01:39:05PM +0200, Toke Høiland-Jørgensen wrote:
>> Vladimir Oltean writes:
>>
>> > On Thu, Apr 01, 2021 at 01:26:02PM +0200, Toke Høiland-Jørgensen wrote:
>> >> > +int enetc_xdp_xmit(
Vladimir Oltean writes:
> On Wed, Mar 31, 2021 at 10:20:18PM +, patchwork-bot+netdev...@kernel.org
> wrote:
>> Hello:
>>
>> This series was applied to netdev/net-next.git (refs/heads/master):
>>
>> On Wed, 31 Mar 2021 23:08:48 +0300 you wrote:
>> > From: Vladimir Oltean
>> >
>> > This serie
Vladimir Oltean writes:
> From: Vladimir Oltean
>
> The driver implementation of the XDP_REDIRECT action reuses parts from
> XDP_TX, most notably the enetc_xdp_tx function which transmits an array
> of TX software BDs. Only this time, the buffers don't have DMA mappings,
> we need to create them
Hangbin Liu writes:
> On Wed, Mar 31, 2021 at 03:41:17PM +0200, Toke Høiland-Jørgensen wrote:
>> > @@ -1491,13 +1492,20 @@ static __always_inline int
>> > __bpf_xdp_redirect_map(struct bpf_map *map, u32 ifind
>> > */
>> >ri->m
Hangbin Liu writes:
> This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to extend
> xdp_redirect_map for broadcast support.
>
> Keep the general data path in net/core/filter.c and the native data
> path in kernel/bpf/devmap.c so we can use direct calls to get better
> performace.
up existing resources for non-zero prog_id as that implies that
> XDP program is present on the underlying net device. This in turn makes
> it easier to follow, especially the teardown part of both branches.
>
> Signed-off-by: Maciej Fijalkowski
Acked-by: Toke Høiland-Jørgensen
Daniel Borkmann writes:
> On 3/30/21 10:39 PM, Andrii Nakryiko wrote:
>> On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi
>> wrote:
>>> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote:
Is there some succinct but complete enough documentation/tutorial/etc
that I can
Andrii Nakryiko writes:
> On Sun, Mar 28, 2021 at 1:11 AM Kumar Kartikeya Dwivedi
> wrote:
>>
>> On Sun, Mar 28, 2021 at 10:12:40AM IST, Andrii Nakryiko wrote:
>> > Is there some succinct but complete enough documentation/tutorial/etc
>> > that I can reasonably read to understand kernel APIs pro
Maciej Fijalkowski writes:
> On Mon, Mar 29, 2021 at 04:09:33PM +0200, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>> > On Mon, Mar 29, 2021 at 01:05:44PM +0200, Toke Høiland-Jørgensen wrote:
>> >> Maciej Fijalkowski writes:
>> &g
Jesper Dangaard Brouer writes:
> On Mon, 29 Mar 2021 16:00:39 +0800
> Ong Boon Leong wrote:
>
>> xdp_return_frame() may be called outside of NAPI context to return
>> xdpf back to page_pool. xdp_return_frame() calls __xdp_return() with
>> napi_direct = false. For page_pool memory model, __xdp_re
Maciej Fijalkowski writes:
> On Mon, Mar 29, 2021 at 01:05:44PM +0200, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>> > Currently, if there are multiple xdpsock instances running on a single
>> > interface and in case one of the instances is
Vlad Buslov writes:
> On Thu 25 Mar 2021 at 14:00, Kumar Kartikeya Dwivedi wrote:
>> This adds functions that wrap the netlink API used for adding,
>> manipulating, and removing filters and actions. These functions operate
>> directly on the loaded prog's fd, and return a handle to the filter an
Maciej Fijalkowski writes:
> Currently, if there are multiple xdpsock instances running on a single
> interface and in case one of the instances is terminated, the rest of
> them are left in an inoperable state due to the fact of unloaded XDP
> prog from interface.
>
> Consider the scenario below
Alexei Starovoitov writes:
> On Sat, Mar 27, 2021 at 09:32:58PM -0700, Andrii Nakryiko wrote:
>> > I think it's better to start with new library for tc/xdp and have
>> > libbpf as a dependency on that new lib.
>> > For example we can add it as subdir in tools/lib/bpf/.
>> >
>> > Similarly I think
Ido Schimmel writes:
> From: Ido Schimmel
>
> Test that all possible combinations of inner and outer ECN bits result
> in the correct inner ECN marking according to RFC 6040 4.2.
>
> Signed-off-by: Ido Schimmel
> Reviewed-by: Petr Machata
Acked-by: Toke Høiland-Jørgensen
ed-off-by: Ido Schimmel
> Reviewed-by: Petr Machata
Huh, I had no idea there was a caller in the driver - thanks for fixing
that!
Acked-by: Toke Høiland-Jørgensen
Alexei Starovoitov writes:
> On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote:
>> This adds some basic tests for the low level bpf_tc_* API and its
>> bpf_program__attach_tc_* wrapper on top.
>
> *_block() apis from patch 3 and 4 are not covered by this selftest.
> Why were
Maciej Fijalkowski writes:
> On Thu, Mar 25, 2021 at 12:38:07AM +0100, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>> > On Mon, Mar 22, 2021 at 10:47:09PM +0100, Toke Høiland-Jørgensen wrote:
>> >> Maciej Fijalkowski writes:
>> &g
Andrii Nakryiko writes:
>> Ah, thanks! I always get confused about CHECK() as well! Maybe it should
>> be renamed to ASSERT()? But that would require flipping all the if()
>> statements around them as well :/
>
> Exactly, it's the opposite of assert (ASSERT_NOT %-), that
> CHECK(!found) is "asse
Alexei Starovoitov writes:
> On 3/26/21 3:11 AM, Toke Høiland-Jørgensen wrote:
>> Martin KaFai Lau writes:
>>
>>> On Thu, Mar 25, 2021 at 11:02:23PM +0100, Toke Høiland-Jørgensen wrote:
>>>> Martin KaFai Lau writes:
>>>>
>>>>&g
Martin KaFai Lau writes:
> On Thu, Mar 25, 2021 at 11:02:23PM +0100, Toke Høiland-Jørgensen wrote:
>> Martin KaFai Lau writes:
>>
>> > This patch adds support to BPF verifier to allow bpf program calling
>> > kernel function directly.
>>
>
, just enforcing GPL-only for the struct_ops
program type seems like the simplest way to fix this.
v3: No change
v2: Move check to the top of check_struct_ops_btf_id().
Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf")
Acked-by: Martin KaFai Lau
Signed-off-by: To
rewriting bpf_dctcp's
license in memory.
- Check for the verifier reject message instead of just the return code.
Acked-by: Martin KaFai Lau
Signed-off-by: Toke Høiland-Jørgensen
---
.../selftests/bpf/prog_tests/bpf_tcp_ca.c | 44 +++
.../selftests/bpf/progs/bpf_tcp_no
Andrii Nakryiko writes:
> On Thu, Mar 25, 2021 at 2:11 PM Toke Høiland-Jørgensen
> wrote:
>>
>> This adds a selftest to check that the verifier rejects a TCP CC struct_ops
>> with a non-GPL license.
>>
>> v2:
>> - Use a minimal struct_ops BP
Martin KaFai Lau writes:
> This patch adds support to BPF verifier to allow bpf program calling
> kernel function directly.
Hi Martin
This is exciting stuff! :)
Just one quick question about this:
> [ For the future calling function-in-kernel-module support, an array
> of module btf_fds can
Toke Høiland-Jørgensen
---
.../selftests/bpf/prog_tests/bpf_tcp_ca.c | 44 +++
.../selftests/bpf/progs/bpf_nogpltcp.c| 19
2 files changed, 63 insertions(+)
create mode 100644 tools/testing/selftests/bpf/progs/bpf_nogpltcp.c
diff --git a/tools/testing/selftest
, just enforcing GPL-only for the struct_ops
program type seems like the simplest way to fix this.
v2: Move check to the top of check_struct_ops_btf_id().
Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf")
Acked-by: Martin KaFai Lau
Signed-off-by: Toke Høiland
Martin KaFai Lau writes:
> On Thu, Mar 25, 2021 at 04:40:34PM +0100, Toke Høiland-Jørgensen wrote:
>> This adds a selftest to check that the verifier rejects a TCP CC struct_ops
>> with a non-GPL license. To save having to add a whole new BPF object just
>> for this, re
Martin KaFai Lau writes:
> On Thu, Mar 25, 2021 at 04:40:33PM +0100, Toke Høiland-Jørgensen wrote:
>> With the introduction of the struct_ops program type, it became possible to
>> implement kernel functionality in BPF, making it viable to use BPF in place
>> of a regular ke
This adds a selftest to check that the verifier rejects a TCP CC struct_ops
with a non-GPL license. To save having to add a whole new BPF object just
for this, reuse the dctcp CC, but rewrite the license field before loading.
Signed-off-by: Toke Høiland-Jørgensen
---
.../selftests/bpf
mechanism, just enforcing GPL-only for the struct_ops
program type seems like the simplest way to fix this.
Fixes: 0baf26b0fcd7 ("bpf: tcp: Support tcp_congestion_ops in bpf")
Signed-off-by: Toke Høiland-Jørgensen
---
kernel/bpf/verifier.c | 5 +
1 file changed, 5 insertions(+)
diff --gi
Maciej Fijalkowski writes:
> On Mon, Mar 22, 2021 at 10:47:09PM +0100, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>> > Currently, if there are multiple xdpsock instances running on a single
>> > interface and in case one of the instances is
Hangbin Liu writes:
> On Thu, Mar 18, 2021 at 03:19:47PM +0100, Toke Høiland-Jørgensen wrote:
>> Hangbin Liu 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
Maciej Fijalkowski writes:
> Currently, if there are multiple xdpsock instances running on a single
> interface and in case one of the instances is terminated, the rest of
> them are left in an inoperable state due to the fact of unloaded XDP
> prog from interface.
>
> Consider the scenario below
Hangbin Liu 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
Cong Wang writes:
> On Mon, Mar 15, 2021 at 2:07 PM Jakub Kicinski wrote:
>>
>> I thought pfifo was supposed to be "lockless" and this change
>> re-introduces a lock between producer and consumer, no?
>
> It has never been truly lockless, it uses two spinlocks in the ring buffer
> implementation
-by: Kumar Kartikeya Dwivedi
Acked-by: Toke Høiland-Jørgensen
Hangbin Liu writes:
> This patch add two flags BPF_F_BROADCAST and BPF_F_EXCLUDE_INGRESS to extend
> xdp_redirect_map for broadcast support.
>
> Keep the general data path in net/core/filter.c and the native data
> path in kernel/bpf/devmap.c so we can use direct calls to get better
> performace.
Kumar Kartikeya Dwivedi writes:
> Otherwise, there exists a small window between the opening and closing
> of the socket fd where it may leak into processes launched by some other
> thread.
>
> Signed-off-by: Kumar Kartikeya Dwivedi
FYI, you should be tagging patches with the tree they are targ
quot;barriers" but reworded. Acquire/release are also
> barriers.
Right, that text is better - thanks!
Acked-by: Toke Høiland-Jørgensen
changing the format specifier and reversing the sign of negative time
values.
Fixes: 71c0cb26 ("Add support for CAKE qdisc")
Signed-off-by: Toke Høiland-Jørgensen
---
tc/q_cake.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tc/q_cake.c b/tc/q_cake.c
index b7
Björn Töpel writes:
> On 2021-03-01 17:08, Toke Høiland-Jørgensen wrote:
>> Björn Töpel writes:
>>
>>> From: Björn Töpel
>>>
>>> Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
>>> kernel-side. By updating the rings for load-ac
Björn Töpel writes:
> From: Björn Töpel
>
> Now that the AF_XDP rings have load-acquire/store-release semantics,
> move libbpf to that as well.
>
> The library-internal libbpf_smp_{load_acquire,store_release} are only
> valid for 32-bit words on ARM64.
>
> Also, remove the barriers that are no l
Björn Töpel writes:
> From: Björn Töpel
>
> Currently, the AF_XDP rings uses smp_{r,w,}mb() fences on the
> kernel-side. By updating the rings for load-acquire/store-release
> semantics, the full barrier on the consumer side can be replaced with
> improved performance as a nice side-effect.
>
>
Björn Töpel writes:
> On 2021-02-26 12:40, Björn Töpel wrote:
>> On 2021-02-26 12:37, Toke Høiland-Jørgensen wrote:
>
> [...]
>
>>>
>>> (That last paragraph above is why I asked if you updated the performance
>>> numbers in the cover letter; removing
Björn Töpel writes:
> On 2021-02-26 12:35, Toke Høiland-Jørgensen wrote:
>> Björn Töpel writes:
>>
>>> Hi XDP-folks,
>>>
>>> This two patch series contain two optimizations for the
>>> bpf_redirect_map() helper and the xdp_do_redirect() funct
ff-by: Björn Töpel
Nice! I agree that this is a much nicer approach! :)
(That last paragraph above is why I asked if you updated the performance
numbers in the cover letter; removing an additional function call should
affect those, right?)
Acked-by: Toke Høiland-Jørgensen
Björn Töpel writes:
> Hi XDP-folks,
>
> This two patch series contain two optimizations for the
> bpf_redirect_map() helper and the xdp_do_redirect() function.
>
> The bpf_redirect_map() optimization is about avoiding the map lookup
> dispatching. Instead of having a switch-statement and selectin
uired/used, and not unconditionally.
>
> rfc->v1: Use map_id, and remove bpf_clear_redirect_map(). (Toke)
>
> Reviewed-by: Maciej Fijalkowski
> Signed-off-by: Björn Töpel
Very cool! Also a small nit below, but otherwise:
Acked-by: Toke Høiland-Jørgensen
> ---
> include/linux/f
n is automatically selected by the BPF verifier.
>
> rfc->v1: Get rid of the macro and use __always_inline. (Jesper)
>
> Signed-off-by: Björn Töpel
Nice! Way better with the __always_inline. One small nit below, but
otherwise:
Acked-by: Toke Høiland-Jørgensen
>
Joe Stringer writes:
> On Wed, Feb 17, 2021 at 5:55 AM Toke Høiland-Jørgensen
> wrote:
>>
>> Joe Stringer writes:
>> > Given the relative success of the process around bpf-helpers(7) to
>> > encourage developers to document their user-facing changes,
e header.
I like the approach, and I don't think it's too onerous to require
updates to the documentation everywhere like we (as you note) already do
for helpers.
So with that, please feel free to add my enthusiastic:
Acked-by: Toke Høiland-Jørgensen
Marek Majtyka writes:
> On Fri, Feb 12, 2021 at 3:05 AM Alexei Starovoitov
> wrote:
>>
>> On Thu, Feb 11, 2021 at 5:26 PM Jakub Kicinski wrote:
>> >
>> > Perhaps I had seen one too many vendor incompatibility to trust that
>> > adding a driver API without a validation suite will result in somet
Björn Töpel writes:
> On 2021-02-15 21:49, John Fastabend wrote:
>> Maciej Fijalkowski wrote:
>>> Currently, if there are multiple xdpsock instances running on a single
>>> interface and in case one of the instances is terminated, the rest of
>>> them are left in an inoperable state due to the fa
John Fastabend writes:
> Toke Høiland-Jørgensen wrote:
>> John Fastabend writes:
>>
>> >> > However, in libxdp we can solve the original problem in a different way,
>> >> > and in fact I already suggested to Magnus that we should do this (see
Maciej Fijalkowski writes:
> On Mon, Feb 15, 2021 at 08:35:29PM +0100, Toke Høiland-Jørgensen wrote:
>> Björn Töpel writes:
>>
>> > On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
>> >> Maciej Fijalkowski writes:
>> >>
>> >>>
John Fastabend writes:
>> > However, in libxdp we can solve the original problem in a different way,
>> > and in fact I already suggested to Magnus that we should do this (see
>> > [1]); so one way forward could be to address it during the merge in
>> > libxdp? It should be possible to address th
Björn Töpel writes:
> On 2021-02-15 18:07, Toke Høiland-Jørgensen wrote:
>> Maciej Fijalkowski writes:
>>
>>> Currently, if there are multiple xdpsock instances running on a single
>>> interface and in case one of the instances is terminated, the rest of
&
Maciej Fijalkowski writes:
> Currently, if there are multiple xdpsock instances running on a single
> interface and in case one of the instances is terminated, the rest of
> them are left in an inoperable state due to the fact of unloaded XDP
> prog from interface.
>
> To address that, step away
Jakub Kicinski writes:
> On Wed, 10 Feb 2021 11:53:53 +0100 Toke Høiland-Jørgensen wrote:
>> >> I am a bit confused now. Did you mean validation tests of those XDP
>> >> flags, which I am working on or some other validation tests?
>> >> What should these
Jakub Kicinski writes:
> On Wed, 3 Feb 2021 13:50:59 +0100 Marek Majtyka wrote:
>> On Tue, Feb 2, 2021 at 8:34 PM Jakub Kicinski wrote:
>> > On Tue, 02 Feb 2021 13:05:34 +0100 Toke Høiland-Jørgensen wrote:
>> > > Awesome! And sorry for not replying straight away
Hangbin Liu writes:
> On Wed, Feb 03, 2021 at 06:53:20PM -0800, John Fastabend wrote:
>> Hangbin Liu wrote:
>> > Hi Daniel, Alexei,
>> >
>> > It has been one week after Maciej, Toke, John's review/ack. What should
>> > I do to make a progress for this patch set?
>> >
>>
>> Patchwork is usually
1 - 100 of 1105 matches
Mail list logo
