Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752204AbdHOFCO (ORCPT ); Tue, 15 Aug 2017 01:02:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44064 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751509AbdHOFCM (ORCPT ); Tue, 15 Aug 2017 01:02:12 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6A48B769E2 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.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: "Michael S. Tsirkin" Cc: Jakub Kicinski , davem@davemloft.net, 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> <8876b3d1-699c-d033-e855-34b24a709c81@redhat.com> <20170814185951-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: <1f2ad15c-967d-fee1-b483-891f91682d9e@redhat.com> Date: Tue, 15 Aug 2017 13:02:05 +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: <20170814185951-mutt-send-email-mst@kernel.org> 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.27]); Tue, 15 Aug 2017 05:02:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 54 On 2017年08月15日 00:01, Michael S. Tsirkin wrote: > On Sat, Aug 12, 2017 at 10:48:49AM +0800, Jason Wang wrote: >> >> 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 > What did you test btw? Pktgen > The biggest issue would be with something like > UDP with short packets. > Note that we do this only when sndbuf is INT_MAX. So this is probably not an issue. The only thing matter is more stress to page allocator, but according to the result of pktgen it was very small that could be ignored. Thanks