Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968135AbXEHOMV (ORCPT ); Tue, 8 May 2007 10:12:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S968127AbXEHOMU (ORCPT ); Tue, 8 May 2007 10:12:20 -0400 Received: from khc.piap.pl ([195.187.100.11]:48305 "EHLO khc.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967418AbXEHOMT (ORCPT ); Tue, 8 May 2007 10:12:19 -0400 To: Lennert Buytenhek Cc: Michael-Luke Jones , Jeff Garzik , netdev@vger.kernel.org, lkml , Russell King , ARM Linux Mailing List Subject: Re: [PATCH] Intel IXP4xx network drivers v.3 - QMGR References: <5BB7E1AB-5CE1-43C8-8CE3-E0DE0236BD09@cam.ac.uk> <86D26EBE-5899-468F-9C79-23E83E0DE04B@cam.ac.uk> <20070508113232.GA32055@xi.wantstofly.org> From: Krzysztof Halasa Date: Tue, 08 May 2007 16:12:17 +0200 In-Reply-To: <20070508113232.GA32055@xi.wantstofly.org> (Lennert Buytenhek's message of "Tue, 8 May 2007 13:32:32 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1749 Lines: 38 Lennert Buytenhek writes: > The queue manager interrupts should probably be implemented as an > irqchip, in the same way that GPIO interrupts are implemented. (I.e. > allocate 'real' interrupt numbers for them, and use the interrupt > cascade mechanism.) You probably want to have separate irqchips for > the upper and lower halves, too. This way, drivers can just use > request_irq() instead of having to bother with platform-specific > qmgr_set_irq() methods. Is there a sample somewhere? > As with Christian's driver, I don't know whether an SRAM allocator > makes much sense. We can just set up a static allocation map for the > in-tree drivers and leave out the allocator altogether. I.e. I don't > think it's worth the complexity (and just because the butt-ugly Intel > code has an allocator isn't a very good reason. :-) It's a very simple allocator. I don't whink we have enough SRAM without it. For now it would work but it's probably too small for all potential users at a time. There may be up to 6 Ethernet ports (not sure about hardware status, not yet supported even by Intel) - 7 queues * 128 entries each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something for TX, and then crypto, and maybe other things. Current allocator have its potential problems, but they can be solved internally (fragmentation, be we tend to use only 128-entry queues (RX and TX-ready Ethernet pool) and short, 16-entry ones (TX) - easy to deal with). -- Krzysztof Halasa - 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/