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 page is writable.
Is to store the XDP meta-data in-packet-data memory area, e.g. after
the end-of packet-data like skb_shared_info does.

One problem with storing in-packet-data, is that this memory area is
DMA mapped, and thus the device might have invalidated the cache mem
state. We might be lucky that HW does not cache invalidate entire
page. (We should somehow verify this).

Another issue with storing in-packet-data, is information leaking.
For a use-case of XDP delivering packet-pages faster to e.g. a guest
OS, then we should avoid leaking information (like pointers) in
packet-data.

Will the XDP meta-data be small enough, that we can store it on the
stack of the caller of the XDP-hook? And will this be valid long
enough, as this info is needed by the XDP TX/forward step?

--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer

On Thu, Jun 2, 2016 at 8:24 AM, Brenden Blanco <bblanco@...> wrote:

On Thu, Jun 2, 2016 at 3:16 AM, Jesper Dangaard Brouer <brouer@...>
wrote:

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 page is writable.
Is to store the XDP meta-data in-packet-data memory area, e.g. after
the end-of packet-data like skb_shared_info does.

One problem with storing in-packet-data, is that this memory area is
DMA mapped, and thus the device might have invalidated the cache mem
state. We might be lucky that HW does not cache invalidate entire
page. (We should somehow verify this).

Another issue with storing in-packet-data, is information leaking.
For a use-case of XDP delivering packet-pages faster to e.g. a guest
OS, then we should avoid leaking information (like pointers) in
packet-data.

Will the XDP meta-data be small enough, that we can store it on the
stack of the caller of the XDP-hook? And will this be valid long
enough, as this info is needed by the XDP TX/forward step?

The plan is to keep it on the stack. It should be quite small. So far it is
a data pointer, a data_end pointer, and we can add a rx hash later. The
current implementation keeps these in a per-cpu static variable, but I plan
to move it to the stack for the next revision.

+1
the stack should be sufficient for long time.