Brenden Blanco <bblanco@...> wrote: I'm doing my usual benchmark driven development. Which means I'm currently benchmarking the lowest RX layer of the drivers and just dropping packets inside

Alexei Starovoitov <alexei.starovoitov@...> wrote: Yes, but we might as well start up with making the allocator hacks in mlx4 more generic, when adding recycle. But still keep them locally in th

I've started a separate document for designing my page-pool idea. I see the page-pool as a component, for allowing fast forwarding with XDP, at the packet-page level, cross device. I want your input o

Tom Herbert <tom@...> wrote: I'm not sure how you can get lockless TX with only one XDP-TX queue. Remember we have to build in bulk TX from day one. Why? Remember the TX tailptr write is c

Tom Herbert <tom@...> wrote: I almost agree, but there are some details ;-) Yes, for XDP-TX we likely cannot piggy-back on the normal stack TX queues (like we do on the RX queues). Thus, w

Alexei Starovoitov <alexei.starovoitov@...> wrote: I agree that driver choose TX queue to use to avoid conflicts, allowing lockless access. I think XDP/BPF "forward"-mode" should always select a

[...] The page-pool doc section "Feedback loop" was primarily about how the page-pool's need to recycle, offer a way to handle and implement flow control. The doc identified two states, but you just i

Tom Herbert via iovisor-dev <iovisor-dev@...> wrote: [...] I'm very interested in the project. But it is not likely I can attend the mini-conference due to travel funding restrictions. (

It is a fundamental requirement that the RX pages (handed over to XDP) are writable. This is usually _not_ the case in NIC drivers. Thus, the current XDP prove-of-concept code violates the DMA API. (W

Many NICs today does VLAN acceleration by delivering the VLAN TCI in the RX descriptor, and stripping/starting the packet-data after the VLAN header. For XDP this special case handling for VLANs is an

I also want a XDP/eBPF hook placed at TX DMA completion time, or when the page is recycled back to the page-pool. This will allow innovating more advanced DDoS filter solutions, as this creates a feed

Once pages comes from the page-pool, then we actually "own" the struct-page. Thus, we do have the option of storing some meta-data inside struct-page. Another option, given our requirement that the RX

What should be the content of the XDP meta-data structure? I find the HW RX-hash very useful for DDoS filtering, and I would like for it to survive until TX completion. Do we need the (page-)offset an

Tom Herbert via iovisor-dev <iovisor-dev@...> wrote: Does this ILA router do multi-leg routing? If not, then I would add the use case for "normal" routing. Use-case: DDoS filter - This w

Tom Herbert via iovisor-dev <iovisor-dev@...> wrote: [...] [...] Given I'll not participate physically, I'll give my page-pool status here. The page-pool idea was presented at MM-summit

Alexei Starovoitov <alexei.starovoitov@...> wrote: [...] Strange I get: $ sudo ./test_maps failed to create per-cpu arraymap 'Operation not permitted' strace says: bpf(BPF_MAP_CREATE, {map_type=

Alexei Starovoitov <alexei.starovoitov@...> wrote: # ulimit -l unlimited # ./test_maps test_maps: OK Then it works, thanks. Maybe we could provide some better feedback from the test program, as

How easy is it to extend the XDP/eBPF program with a new input parameter? I see the need for providing the input "source-port" to the eBPF program. E.g. needed when implementing a basic learning bridg

Would it make sense from a hardware point of view, to split the XDP eBPF program into two stages. Stage-1: Filter (restricted eBPF / no-helper calls) Stage-2: Program Then the HW can choose to offload

I actually disagree. I _do_ want to use the "filter" part of eBPF to direct to NIC queues, and then run a single/specific XDP program on that queue. Why to I want this? This part of solving a very fun