On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote:
> >> There may be up to 6 Ethernet ports (not sure about hardware

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

> >

> > You're unlikely to be using all of those at the same time, though.

>

> That's the point.

>

> > And what do you do if the user does compile all of these features into

> > his kernel and then tries to use them all at the same time?  Return

> > -ENOMEM?

>

> If he is able to do so, yes - there is nothing we can do. But

> I suspect a single machine would not have all possible hardware.

> The problem is, we don't know what would it have, so it must be

> dynamic.

Well, you _would_ like to have a way to make sure that all the

capabilities on the board can be used.  If you have a future ixp4xx

based board with 16 ethernet ports, you don't want 'ifconfig eth7 up'

to give you -ENOMEM just because we ran out of SRAM.
The way I see it, that means that you do want to scale back your

other SRAM allocations if you know that you're going to need a lot

of SRAM (say, for ethernet RX/TX queues.)
Either you can do this with an ugly hack a la:
	/*

	 * The FOO board has many ethernet ports, and runs out of

	 * SRAM prematurely if we use the default TX/RX ring sizes.

	 */

	#ifdef CONFIG_MACH_IXP483_FOO_BOARD

	#define IXP4XX_ETH_RXTX_QUEUE_SIZE	32

	#else

	#define IXP4XX_ETH_RXTX_QUEUE_SIZE	256

	#endif
Or you can put this knowledge in the board support code (cleaner, IMHO.)
E.g. let arch/arm/mach-ixp4xx/nslu2.c decide, at platform device

instantiation time, which region of queue SRAM can be used by which

queue, and take static allocations for things like the crypto unit

into account.  (This is just one form of that idea, there are many

different variations.)
That way, you can _guarantee_ that you'll always have enough SRAM

to be able to use the functionality that is exposed on the board you

are running on (which is a desirable property, IMHO), which is

something that you can't achieve with an allocator, as far as I can

see.
I'm not per se against the allocator, I just think that there are

problems (running out of SRAM, fragmentation) that can't be solved

by the allocator alone (SRAM users have to be aware which other SRAM

users there are in the system, while the idea of the allocator is to

insulate these users from each other), and any solution that solves

those two problems IMHO also automatically solves the problem that

the allocator is trying to solve.

-

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/