Lennert Buytenhek <buytenh@wantstofly.org> writes:

quoted text
> 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?

quoted text
> 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
-
unsubscribe notice
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/