Hello, On Tue, 2018-03-27 at 18:59 +0200, Björn Töpel wrote: > From: Björn Töpel <bjorn.to...@intel.com> > > optimized for high performance packet processing and, in upcoming > patch sets, zero-copy semantics. In this v2 version, we have removed > all zero-copy related code in order to make it smaller, simpler and > hopefully more review friendly. This RFC only supports copy-mode for > the generic XDP path (XDP_SKB) for both RX and TX and copy-mode for > RX >
... > > How is then packets distributed between these two XSK? We have > introduced a new BPF map called XSKMAP (or BPF_MAP_TYPE_XSKMAP in > full). The user-space application can place an XSK at an arbitrary > place in this map. The XDP program can then redirect a packet to a > specific index in this map and at this point XDP validates that the > XSK in that map was indeed bound to that device and queue number. If > not, the packet is dropped. If the map is empty at that index, the > packet is also dropped. This also means that it is currently > mandatory > to have an XDP program loaded (and one XSK in the XSKMAP) to be able > to get any traffic to user space through the XSK. If I get it correctly, this feature will have to be used to bound multiple sockets to a single queue and the eBPF filter will be responsible of the load balancing. Am I correct ? > AF_XDP can operate in two different modes: XDP_SKB and XDP_DRV. If > the > driver does not have support for XDP, or XDP_SKB is explicitly chosen ... Thanks a lot for this work, I'm gonna try to implement this in Suricata. Best regards, -- Eric Leblond
