Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365Ab3EUOUN (ORCPT ); Tue, 21 May 2013 10:20:13 -0400 Received: from mail-ie0-f177.google.com ([209.85.223.177]:44119 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750785Ab3EUOUL (ORCPT ); Tue, 21 May 2013 10:20:11 -0400 MIME-Version: 1.0 In-Reply-To: <519B1A2B.4010909@linux.intel.com> References: <20130520101552.14133.45953.stgit@ladj378.jer.intel.com> <20130520101622.14133.21998.stgit@ladj378.jer.intel.com> <519B1A2B.4010909@linux.intel.com> From: Willem de Bruijn Date: Tue, 21 May 2013 10:19:39 -0400 Message-ID: Subject: Re: [PATCH v3 net-next 3/4] ixgbe: Add support for ndo_ll_poll To: Eliezer Tamir Cc: Or Gerlitz , Dave Miller , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Jesse Brandeburg , Don Skidmore , e1000-devel@lists.sourceforge.net, Andi Kleen , HPA , Eliezer Tamir Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2230 Lines: 54 On Tue, May 21, 2013 at 2:54 AM, Eliezer Tamir wrote: > On 20/05/2013 23:20, Or Gerlitz wrote: >> >> On Mon, May 20, 2013 at 1:16 PM, Eliezer Tamir >> wrote: >>> >>> Add the ixgbe driver code implementing ndo_ll_poll. >>> It should be easy for other drivers to do something similar >>> in order to enable support for CONFIG_INET_LL_RX_POLL >> >> >> I am not sure, > > > Willem ported this to , his > feedback was that it was not a major effort. The core ndo_ll_poll implementation is generally a subset of a device driver's existing napi callback. It cleans the queues, but it skips napi_complete and unmasking of the IRQ. + ixgbe_for_each_ring(ring, q_vector->rx) { + found = ixgbe_clean_rx_irq(q_vector, ring, 4); + if (found) + break; + } A subtle difference in the above code vs ixgbe_poll is that the callback returns as soon as some data arrived on a queue, as opposed to iterating over all queues. The budget is lower, too. Since not all data arriving is necessarily destined towards polling socket, this may or may not be an improvement. Besides that, the driver has to mark the packet with ll_mark_skb(&cq->napi, skb); On devices where tx completion interrupts share the same IRQ as rx interrupts, the driver may also have to clean the tx queue once in a while (at obvious tail latency cost). LLS does not disable the IRQ, but I think the suggestion was to set its moderation threshold very high to avoid net_rx_action/LLS lock contention. If so, starvation may occur. The most difficult bit is handling mutual exclusion with the interrupt-driven receive path. The ixgbe port has its own internal locking mechanism in anticipation of future use cases that can be lock-free. As first approximation, I just took the napi->poll_lock, similar to how netpoll handles mutual exclusion with net_rx_action. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/