On 04/19/2017 10:02 PM, Andy Gospodarek wrote:
On Tue, Apr 18, 2017 at 09:58:56PM +0200, Jesper Dangaard Brouer wrote:As I argued in NetConf presentation[1] (from slide #9) we need a port mapping table (instead of using ifindex'es). Both for supporting other "port" types than net_devices (think sockets), and for sandboxing what XDP can bypass. I want to create a new XDP action called XDP_REDIRECT, that instruct XDP to send the xdp_buff to another "port" (get translated into a net_device, or something else depending on internal port type). Looking at the userspace/eBPF interface, I'm wondering what is the best API for "returning" this port number from eBPF? The options I see is: 1) Split-up the u32 action code, and e.g let the high-16-bit be the port number and lower-16bit the (existing) action verdict. Pros: Simple API Cons: Number of ports limited to 64KPractically speaking this may be seem reserving 64k for the port number might be enough space, but I would also like to see a new return option for flags so I start to get concerned about space. Daniel also hightlights the fact that encoding the port in the action may does not leave room for flags and could get confusing. One unfortunate side-effect of dropping or transmitting frames with XDP is that we lose the opportunity to statistically sample in netfilter since the frames were dropped so early and I'd like to bring that back with a call to parse flags and possibly call psample_sample_packet() after the xdp action. Packet sampling cannot simply be an action since there are times when a frame should be dropped but should also be sampled, so it seems logical to add this as a flag.
Hmm, you can do that already today with bpf_xdp_event_output() helper and the program decides when to sample and what custom meta data to prepend along with the (partial or full) xdp packet, see also [1], slide 11 for the "XDP dump" part. No need to change drivers for this, psample_sample_packet() would also be slower. [1] http://netdevconf.org/2.1/slides/apr6/zhou-netdev-xdp-2017.pdf