Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752114AbdHLCtA (ORCPT ); Fri, 11 Aug 2017 22:49:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59826 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751731AbdHLCs6 (ORCPT ); Fri, 11 Aug 2017 22:48:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 96CE77DEF2 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jasowang@redhat.com Subject: Re: [PATCH net-next V2 3/3] tap: XDP support To: Jakub Kicinski Cc: davem@davemloft.net, mst@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Borkmann References: <1502451678-17358-1-git-send-email-jasowang@redhat.com> <1502451678-17358-4-git-send-email-jasowang@redhat.com> <20170811161223.6808008d@cakuba.netronome.com> From: Jason Wang Message-ID: <8876b3d1-699c-d033-e855-34b24a709c81@redhat.com> Date: Sat, 12 Aug 2017 10:48:49 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170811161223.6808008d@cakuba.netronome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Sat, 12 Aug 2017 02:48:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1293 Lines: 38 On 2017年08月12日 07:12, Jakub Kicinski wrote: > On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote: >> This patch tries to implement XDP for tun. The implementation was >> split into two parts: >> >> - fast path: small and no gso packet. We try to do XDP at page level >> before build_skb(). For XDP_TX, since creating/destroying queues >> were completely under control of userspace, it was implemented >> through generic XDP helper after skb has been built. This could be >> optimized in the future. >> - slow path: big or gso packet. We try to do it after skb was created >> through generic XDP helpers. >> >> Test were done through pktgen with small packets. >> >> xdp1 test shows ~41.1% improvement: >> >> Before: ~1.7Mpps >> After: ~2.3Mpps >> >> xdp_redirect to ixgbe shows ~60% improvement: >> >> Before: ~0.8Mpps >> After: ~1.38Mpps >> >> Suggested-by: Michael S. Tsirkin >> Signed-off-by: Jason Wang > Looks OK to me now :) > > Out of curiosity, you say the build_skb() is for "small packets", and it > seems you are always reserving the 256B regardless of XDP being > installed. Does this have no performance impact on non-XDP case? Have a test, only less than 1% were noticed which I think could be ignored. Thanks