From patchwork Wed Sep 21 15:09:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Hutchings X-Patchwork-Id: 115794 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 33324B6F8E for ; Thu, 22 Sep 2011 01:09:14 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752004Ab1IUPJI (ORCPT ); Wed, 21 Sep 2011 11:09:08 -0400 Received: from exchange.solarflare.com ([216.237.3.220]:7673 "EHLO exchange.solarflare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925Ab1IUPJH (ORCPT ); Wed, 21 Sep 2011 11:09:07 -0400 Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 08:09:06 -0700 Subject: Re: RFS issue: no HW filter for paused stream From: Ben Hutchings To: amirv@mellanox.co.il Cc: Tom Herbert , oren@mellanox.co.il, liranl@mellanox.co.il, netdev@vger.kernel.org, Diego Crupnicoff In-Reply-To: <4E783855.4020907@dev.mellanox.co.il> References: <1316447572.2764.21.camel@bwh-desktop> <4E783855.4020907@dev.mellanox.co.il> Organization: Solarflare Communications Date: Wed, 21 Sep 2011 16:09:02 +0100 Message-ID: <1316617742.2760.18.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) X-OriginalArrivalTime: 21 Sep 2011 15:09:06.0345 (UTC) FILETIME=[6800B990:01CC7870] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18398.005 X-TM-AS-Result: No--20.675100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 2011-09-20 at 09:53 +0300, Amir Vadai wrote: > This will unset the current CPU of the rflow that belongs to the desired > CPU. > The problem is when the stream resumes and it goes to the wrong RXQ - in > our HW, it will be according to RSS, as long as there is no specific > flow steering rule for the stream. Sorry, yes. Told you I didn't test my patch! > We need to unset the current CPU of the rflow of the actual RXQ that the > packet arrived at: [...] > Or even better, not set it in the first place - but I'm not sure I > undersdtand the implications on RPS: > > diff --git a/net/core/dev.c b/net/core/dev.c > index 4b9981c..748acdb 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2654,7 +2654,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff > *skb, > { > u16 tcpu; > > - tcpu = rflow->cpu = next_cpu; > + tcpu = next_cpu; > if (tcpu != RPS_NO_CPU) { > #ifdef CONFIG_RFS_ACCEL > struct netdev_rx_queue *rxqueue; > > But that means we never move the flow to a new CPU in the non- accelerated case. So maybe the proper change would be: --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2652,10 +2652,7 @@ static struct rps_dev_flow * set_rps_cpu(struct net_device *dev, struct sk_buff *skb, struct rps_dev_flow *rflow, u16 next_cpu) { - u16 tcpu; - - tcpu = rflow->cpu = next_cpu; - if (tcpu != RPS_NO_CPU) { + if (next_cpu != RPS_NO_CPU) { #ifdef CONFIG_RFS_ACCEL struct netdev_rx_queue *rxqueue; struct rps_dev_flow_table *flow_table; @@ -2683,16 +2680,16 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb, goto out; old_rflow = rflow; rflow = &flow_table->flows[flow_id]; - rflow->cpu = next_cpu; rflow->filter = rc; if (old_rflow->filter == rflow->filter) old_rflow->filter = RPS_NO_FILTER; out: #endif rflow->last_qtail = - per_cpu(softnet_data, tcpu).input_queue_head; + per_cpu(softnet_data, next_cpu).input_queue_head; } + rflow->cpu = next_cpu; return rflow; } --- END ---