Lennert Buytenhek <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
