Thread (31 messages) flat view 31 messages, 8 authors, 2017-02-14

Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

From: Jesper Dangaard Brouer <hidden>
Date: 2017-02-14 22:29:39

On Tue, 14 Feb 2017 22:08:10 +0000
Edward Cree [off-list ref] wrote:
To me, the sensible interface (which makes the batching explicit to
 the driver, which I think is necessary) is to have an int (or maybe
 unsigned int, which is the return type of xdp_hookfn, I'm not sure
 which is intended) member in struct xdp_buff.

Then the driver can call something like
	XDP_RUN_ARRAY(napi, xdp_array, array_len);
which is semantically equivalent to
	unsigned int i;
	for (i = 0; i < array_len; i++)
		xdp_array[i].ret = xdp_hook_run(napi, xdp_array + i);
Yes, exactly.

I imagined the xdp_array[i].ret would be the XDP action return code.
except that it may run the hooks in 'row-major order'.
No callbacks needed, the driver can just loop over xdp_array reading
 the .ret and applying the relevant action to each packet.

This also has the advantage that the driver knows how many packets it
 might have to process in a single batch (i.e. NAPI_POLL_WEIGHT) and
 can allocate the array statically, whereas an XDP hook that tried to
 transparently be 'helpful' would have to guess and/or use kmalloc.
I also think the driver need to be explicit about batching.

This related to the RX stages I'm talking about.  Saeed is working on
implementing that for mlx5, I got some PoC patches today and I'll soon
test that.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help