From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next] bnx2x: Do Tx handling in a separate tasklet. Date: Mon, 26 Oct 2009 15:28:30 -0700 (PDT) Message-ID: <20091026.152830.75929619.davem@davemloft.net> References: <1256473182.11634.4.camel@lb-tlvb-vladz.il.broadcom.com> <20091025.142059.175260055.davem@davemloft.net> <8628FE4E7912BF47A96AE7DD7BAC0AADCB2CFF1C42@SJEXCHCCR02.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: eilong@broadcom.com, netdev@vger.kernel.org To: vladz@broadcom.com Return-path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:37660 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753452AbZJZW2H (ORCPT ); Mon, 26 Oct 2009 18:28:07 -0400 In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADCB2CFF1C42@SJEXCHCCR02.corp.ad.broadcom.com> Sender: netdev-owner@vger.kernel.org List-ID: From: "Vladislav Zolotarov" Date: Mon, 26 Oct 2009 07:42:27 -0700 > The separation of Tx and Rx interrupt handling gives us the > possibility to properly affinitize the Rx (heavy CPU consuming task) > and Tx (low CPU consuming task) and to ensure that Tx work is done > not long after the Tx interrupt without interference of Rx work thus > letting the user benefit from Tx coalescing configuration in order > to achieve the best performance in each specific scenario. This is > most important in heavy load scenarios with mixed traffic (UDP + TCP > for instance). If we didn't separate Tx and Rx interrupt handling Tx > coalescing configuration was not worth much. There are other issues: 1) Actually, it makes sense to do TX and RX work together, since TX packet liberation makes fresh CPU local packets available for responses generated by RX packet reception. 2) TX packet liberation is not low CPU consumption, it has to perform many atomic instructions, reference socket state, enter the SLAB allocator, potentially liberate netfilter state, etc. Using NAPI also moves the TX freeing into softirq context. If you do it from a hardirq you are making it more expensive. From hardirq the free just puts the SKB on a list, schedules a softirq, then does the real SKB free work from the softirq. This needless SKB list management and softirq scheduling you'll avoid if you do things from softirqs, and thus using NAPI makes sense here.