Lennert Buytenhek  writes:
> The queue manager interrupts should probably be implemented as an

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

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