Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752684AbdHNIoD (ORCPT ); Mon, 14 Aug 2017 04:44:03 -0400 Received: from www62.your-server.de ([213.133.104.62]:33615 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752291AbdHNIoB (ORCPT ); Mon, 14 Aug 2017 04:44:01 -0400 Message-ID: <599162CA.4080504@iogearbox.net> Date: Mon, 14 Aug 2017 10:43:54 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jason Wang CC: davem@davemloft.net, mst@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kubakici@wp.pl Subject: Re: [PATCH net-next V2 3/3] tap: XDP support References: <1502451678-17358-1-git-send-email-jasowang@redhat.com> <1502451678-17358-4-git-send-email-jasowang@redhat.com> In-Reply-To: <1502451678-17358-4-git-send-email-jasowang@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1364 Lines: 39 On 08/11/2017 01:41 PM, Jason Wang wrote: > This patch tries to implement XDP for tun. The implementation was > split into two parts: [...] > @@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile, > skb_reset_network_header(skb); > skb_probe_transport_header(skb, 0); > > + if (generic_xdp) { > + struct bpf_prog *xdp_prog; > + int ret; > + > + rcu_read_lock(); > + xdp_prog = rcu_dereference(tun->xdp_prog); The name generic_xdp is a bit confusing in this context given this is 'native' XDP, perhaps above if (generic_xdp) should have a comment explaining semantics for tun and how it relates to actual generic xdp that sits at dev->xdp_prog, and gets run from netif_rx_ni(). Or just name the bool xdp_handle_gso with a comment that we let the generic XDP infrastructure deal with non-linear skbs instead of having to re-implement the do_xdp_generic() internals, plus a statement that the actual generic XDP comes a bit later in the path. That would at least make it more obvious to read, imho. > + if (xdp_prog) { > + ret = do_xdp_generic(xdp_prog, skb); > + if (ret != XDP_PASS) { > + rcu_read_unlock(); > + return total_len; > + } > + } > + rcu_read_unlock(); > + } > + > rxhash = __skb_get_hash_symmetric(skb); > #ifndef CONFIG_4KSTACKS > tun_rx_batched(tun, tfile, skb, more); >