From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mugunthan V N Subject: Re: TI CPSW Ethernet Tx performance regression Date: Tue, 4 Feb 2014 14:16:22 +0530 Message-ID: <52F0A8DE.8080302@ti.com> References: <1389790129-5721-1-git-send-email-mugunthanvnm@ti.com> <1389808467.11912.9.camel@bwh-desktop.uk.level5networks.com> <52D77716.1020205@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: netdev , Ben Hutchings To: Florian Fainelli Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:40972 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751310AbaBDIqe (ORCPT ); Tue, 4 Feb 2014 03:46:34 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Hi On Tuesday 04 February 2014 12:54 AM, Florian Fainelli wrote: > Ok,the priv pointer when we enter the interrupt handler could point to > e.g: slave 0, so we need to get it re-assigned to the second slave > using cpsw_get_slave_priv(). How do you ensure that "priv" at the > beginning of the interrupt handler does not already point to slave 1? > In that case, is not there a chance to starve slave 0, or at least > cause an excessive latency by exiting the interrupt handler for slave > 1, and then re-entering it for slave 0? devm_request_irq is called with slave 0 priv, so at the beginning of the interrupt it is always slave 0 priv irrespective whether the slave 0 interface is up or not. Regards Mugunthan V N