2018-03-28 23:18 GMT+02:00 Eric Leblond <e...@regit.org>: > 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 ? >
Exactly! The XDP program executing for a certain Rx queue will distribute the packets to the socket(s) in the xskmap. >> 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. > Thanks for trying it out! All input is very much appreciated (clunkiness of API, crashes...)! Björn > Best regards, > -- > Eric Leblond
