From patchwork Sun Jun 10 16:02:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Toshiaki Makita X-Patchwork-Id: 927383 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XHigL5rg"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 413gsV1YG6z9rvt for ; Mon, 11 Jun 2018 02:02:54 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932330AbeFJQCn (ORCPT ); Sun, 10 Jun 2018 12:02:43 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:42417 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932295AbeFJQCh (ORCPT ); Sun, 10 Jun 2018 12:02:37 -0400 Received: by mail-pf0-f193.google.com with SMTP id w7-v6so8942738pfn.9 for ; Sun, 10 Jun 2018 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=yok3wQzu28fT1HxXZy1Q0Rjn9NvF/b0Adxd6S83GuI8=; b=XHigL5rgy1DuO+RzL3Ef5pXw54OjGxA9MW7fD9zYea379xNLG+96k0noZwqW+zxFiB VFfAc2XeF9iLWN7MFofFjVhHWDXGwuLjiQZXMQ/UreTw6oeAMgIzYbZTSl7I/shlpEv6 svdzht16HYFImE+YQ5SJ2RoWBqRj+VgAU10waEQggmRBJDWkUkP/l0wqyOz/h53Anwa/ /b3l+wJbYnrUbK12DswEcHc9H+uZyksD5CFj2iZPOPs4VvtPSjjqAMzG/XgU1YMFEoal NJAy/4J0lqzku2k0doCtqFJ1QzGtDDPYZThKz27Fn5KZEZUhc0szeSHxJqPIi3EDkAeK Oo5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=yok3wQzu28fT1HxXZy1Q0Rjn9NvF/b0Adxd6S83GuI8=; b=D4vJ65RVOxtDnq8dbt9XvrdQdQcbSy6BvMlVIkeD0UEuBh/Wa/tjvdygvmEw7I4EAC IsDop+kHiQw3t5oNzFWzxfNWlJxfaUjH9ONXhqqtTZFbvxWoU4lTHuQ/b7Bs3u8VzbwE KjVd06GYs8JiNOJkn+uBMU07g0ifOipwI0F2MMNvKrlutbNI8Rc+pzygTkR6BdYdKkQ0 Q8mlX6X7tAd0f7KxCTdGmRdJCBCaxAZVCrAtUYkyW7bkplEvL6fZry+Ev9OxaFSptK57 pk9wkGZg5WYPTsQbuq3kr6OsUcGdw/bCp57IK+U4LXoaDqGL5QiAw62T9/8JK28tb9fX c5nA== X-Gm-Message-State: APt69E38A3PsXcUroZd7eUSfbhr0KzqME5c5rqTPThWc9/eH2hyJIODd +1WeFgCSlKJgXxfssxrdE3siJA== X-Google-Smtp-Source: ADUXVKIdwPjIIcSYkJc7BjblUI4VciNbKHCUNkSpvgYinqvd0E5HrM/5jfFffiPZ/ue6ppuIQTQz7Q== X-Received: by 2002:a63:77c9:: with SMTP id s192-v6mr11871766pgc.140.1528646557110; Sun, 10 Jun 2018 09:02:37 -0700 (PDT) Received: from localhost.localdomain (i153-145-22-9.s42.a013.ap.plala.or.jp. [153.145.22.9]) by smtp.gmail.com with ESMTPSA id o87-v6sm56068211pfa.106.2018.06.10.09.02.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 10 Jun 2018 09:02:36 -0700 (PDT) From: Toshiaki Makita To: netdev@vger.kernel.org Cc: Toshiaki Makita , Jesper Dangaard Brouer , Alexei Starovoitov , Daniel Borkmann Subject: [PATCH RFC v2 6/9] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info Date: Mon, 11 Jun 2018 01:02:14 +0900 Message-Id: <20180610160217.3146-7-toshiaki.makita1@gmail.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180610160217.3146-1-toshiaki.makita1@gmail.com> References: <20180610160217.3146-1-toshiaki.makita1@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Toshiaki Makita We need some mechanism to disable napi_direct on calling xdp_return_frame_rx_napi() from some context. When veth gets support of XDP_REDIRECT, it will redirects packets which are redirected from other devices. On redirection veth will reuse xdp_mem_info of the redirection source device to make return_frame work. But in this case .ndo_xdp_xmit() called from veth redirection uses xdp_mem_info which is not guarded by NAPI, because the .ndo_xdp_xmit is not called directly from the rxq which owns the xdp_mem_info. This approach introduces a flag in xdp_mem_info to indicate that napi_direct should be disabled even when _rx_napi variant is used. Signed-off-by: Toshiaki Makita --- include/net/xdp.h | 4 ++++ net/core/xdp.c | 6 ++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/net/xdp.h b/include/net/xdp.h index 2deea7166a34..ea0c80f6c8ee 100644 --- a/include/net/xdp.h +++ b/include/net/xdp.h @@ -41,6 +41,9 @@ enum xdp_mem_type { MEM_TYPE_MAX, }; +/* XDP flags for xdp_mem_info */ +#define XDP_MEM_RF_NO_DIRECT BIT(0) /* don't use napi_direct */ + /* XDP flags for ndo_xdp_xmit */ #define XDP_XMIT_FLUSH (1U << 0) /* doorbell signal consumer */ #define XDP_XMIT_FLAGS_MASK XDP_XMIT_FLUSH @@ -48,6 +51,7 @@ enum xdp_mem_type { struct xdp_mem_info { u32 type; /* enum xdp_mem_type, but known size type */ u32 id; + u32 flags; }; struct page_pool; diff --git a/net/core/xdp.c b/net/core/xdp.c index 9d1f22072d5d..e94f146360b2 100644 --- a/net/core/xdp.c +++ b/net/core/xdp.c @@ -327,10 +327,12 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct, /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */ xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params); page = virt_to_head_page(data); - if (xa) + if (xa) { + napi_direct &= !(mem->flags & XDP_MEM_RF_NO_DIRECT); page_pool_put_page(xa->page_pool, page, napi_direct); - else + } else { put_page(page); + } rcu_read_unlock(); break; case MEM_TYPE_PAGE_SHARED: