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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 14 Feb 2017 23:29:35 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Tom Herbert <tom@...bertland.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>, brouer@...hat.com
Subject: Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

On Tue, 14 Feb 2017 22:08:10 +0000
Edward Cree <ecree@...arflare.com> 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