From patchwork Mon Jun 7 22:30:42 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 54895 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id F40AFB7D47 for ; Tue, 8 Jun 2010 08:30:05 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753581Ab0FGW36 (ORCPT ); Mon, 7 Jun 2010 18:29:58 -0400 Received: from mga14.intel.com ([143.182.124.37]:26213 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753477Ab0FGW35 (ORCPT ); Mon, 7 Jun 2010 18:29:57 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 07 Jun 2010 15:29:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.53,380,1272870000"; d="scan'208";a="286122840" Received: from jrfastab-mobl2.amr.corp.intel.com (HELO [10.24.153.107]) ([10.24.153.107]) by azsmga001.ch.intel.com with ESMTP; 07 Jun 2010 15:29:56 -0700 Message-ID: <4C0D7312.1020300@intel.com> Date: Mon, 07 Jun 2010 15:30:42 -0700 From: John Fastabend User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stephen Hemminger CC: Peter Lieven , "davem@davemloft.net" , "netdev@vger.kernel.org" Subject: Re: RFS seems to have incompatiblities with bridged vlans References: <62C40338-045A-417E-9B90-E59A320E1343@dlh.net> <20100607145910.2458ac87@nehalam> In-Reply-To: <20100607145910.2458ac87@nehalam> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Stephen Hemminger wrote: > On Mon, 7 Jun 2010 22:36:11 +0200 > Peter Lieven wrote: > >> Hi, >> >> i today tried out 2.6.32-rc2 and I see a lot of warning messages like this: >> >> Jun 7 22:33:15 172.21.55.20 kernel: [ 3012.575884] br141 received packet on queue 4, but number of RX queues is 1 >> >> The host is a SMP system with 8 cores, so I think there is expected to be one rx queue per CPU, but it seems >> the bridge iface has only one. >> > > The bridge interface has no queues. It doesn't queue any packets. > The test in receive packet path is not appropriate in this case. > Not sure what the right fix is. Pretending the bridge device has > multiple queues (num_queues == NUM_CPUS) is a possibility but > seems like overhead without real increase in parallelism. > > > There is always a possibility that the underlying device sets the queue_mapping to be greater then num_cpus. Also I suspect the same issue exists with bonding devices. Maybe something like the following is worth while? compile tested only, [PATCH] 8021q: vlan reassigns dev without check queue_mapping recv path reassigns skb->dev without sanity checking the queue_mapping field. This can result in the queue_mapping field being set incorrectly if the new dev supports less queues then the underlying device. This patch just resets the queue_mapping to 0 which should resolve this issue? Any thoughts? The same issue could happen on bonding devices as well. Signed-off-by: John Fastabend --- net/8021q/vlan_core.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) drop: @@ -93,6 +96,9 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp, if (!skb->dev) goto drop; + if (unlikely(skb->queue_mapping >= skb->dev->real_num_tx_queues)) + skb_set_queue_mapping(skb, 0); + for (p = napi->gro_list; p; p = p->next) { NAPI_GRO_CB(p)->same_flow = p->dev == skb->dev && !compare_ether_header( -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c index bd537fc..ad309f8 100644 --- a/net/8021q/vlan_core.c +++ b/net/8021q/vlan_core.c @@ -21,6 +21,9 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp, if (!skb->dev) goto drop; + if (unlikely(skb->queue_mapping >= skb->dev->real_num_tx_queues)) + skb_set_queue_mapping(skb, 0); + return (polling ? netif_receive_skb(skb) : netif_rx(skb));