Hello!
> I still like existing way - it is much simpler (I hope :) to convince
> e1000 developers to fix driver's memory usage
e1000 is not a problem at all. It just has to use pages.
If it is going to use high order allocations, it will suck,
be it order 3 or 2.
> area (does MAX_TCP_HEADER eno
On Mon, Aug 14, 2006 at 05:19:19PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
> > What if we will store array of pages and in shared info
> > just like we have right now. So there will only one destructor.
>
> Seems, this is not enough. Actually, I was asking for your experience
> with ai
Hello!
> e1000 will setup head/data/tail pointers to point to the area in the
> first sg page.
Maybe.
But I still hope this is not necessary, the driver should be able to do
at least primitive header splitting, in that case the header could
be inlined to skb.
Alternatively, header can be copied
On Monday 14 August 2006 09:50, Herbert Xu wrote:
> On Mon, Aug 14, 2006 at 09:45:53AM +0200, Andi Kleen wrote:
> >
> > Even for 1.5k MTU? (which is still the most common case after all)
>
> Ideally they would stay in kmalloc memory. Could you explain the cache
> colouring problem for 1500-byte
On Sun, Aug 13, 2006 at 05:04:31PM +0400, Alexey Kuznetsov ([EMAIL PROTECTED])
wrote:
> Hello!
>
> > E1000 wants 16K buffers for jumbo MTU settings.
> >
> > The reason is that the chip can only handle power-of-2 buffer
> > sizes, and next hop from 9K is 16K.
>
> Let it use pages. Someone should
On Mon, Aug 14, 2006 at 09:45:53AM +0200, Andi Kleen wrote:
>
> Even for 1.5k MTU? (which is still the most common case after all)
Ideally they would stay in kmalloc memory. Could you explain the cache
colouring problem for 1500-byte packets?
Cheers,
--
Visit Openswan at http://www.openswan.or
On Monday 14 August 2006 09:29, Herbert Xu wrote:
> On Mon, Aug 14, 2006 at 07:04:01AM +0200, Andi Kleen wrote:
> >
> > Another reason to move it in the sk_buff would be better cache
> > coloring? Currently on large/small MTU packets it will be always on
> > the same colors.
>
> If we went with
On Mon, Aug 14, 2006 at 07:04:01AM +0200, Andi Kleen wrote:
>
> Another reason to move it in the sk_buff would be better cache
> coloring? Currently on large/small MTU packets it will be always on
> the same colors.
If we went with a fully paged skbs this should be a non-issue, right?
In a ful
> The e1000 issue is just one example of this, another
> would be any attempt to consolidate the TCP retransmit
> queue data management.
Another reason to move it in the sk_buff would be better cache
coloring? Currently on large/small MTU packets it will be always on
the same colors.
-Andi
-
T
Hello!
> E1000 wants 16K buffers for jumbo MTU settings.
>
> The reason is that the chip can only handle power-of-2 buffer
> sizes, and next hop from 9K is 16K.
Let it use pages. Someone should start. :-)
High order allocations are disaster in any case.
> If we store raw kmalloc buffers, we c
On Fri, Aug 11, 2006 at 05:27:30PM -0700, David Miller wrote:
>
> E1000 wants 16K buffers for jumbo MTU settings.
>
> The reason is that the chip can only handle power-of-2 buffer
> sizes, and next hop from 9K is 16K.
>
> It is not possible to tell the chip to only accept 9K packets, you
> must
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 18:00:19 +0400
> > The e1000 issue is just one example of this, another
>
> What is this issue?
E1000 wants 16K buffers for jumbo MTU settings.
The reason is that the chip can only handle power-of-2 buffer
sizes, and next hop fro
Hello!
>> management schemes and to just wrap SKB's around
>> arbitrary pieces of data.
+
> and something clever like a special page_offset encoding
> means "use data, not page".
But for what purpose do you plan to use it?
> The e1000 issue is just one example of this, another
What is this iss
On Tue, Aug 08, 2006 at 04:39:15PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
>
> I'm beginning to think that where we store the
> skb_shared_info() is a weakness of the SKB design.
Food for thoughts - unix sockets can use PAGE_SIZEd chunks of memory
(and they do it almost always), which are
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 09:35:24 +0400
> We can separate kmalloced data from page by using internal page structures
> (lru pointers and PG_slab bit).
Yes, it is one idea.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
On Tue, Aug 08, 2006 at 05:58:39PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 10:36:16 +1000
>
> > I'm not sure whether the problem is where we store skb_shared_info,
> > or the fact that we can't put kmalloc'ed memory into
> > sk
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 10:36:16 +1000
> I'm not sure whether the problem is where we store skb_shared_info,
> or the fact that we can't put kmalloc'ed memory into
> skb_shinfo->frags.
That's a good point.
I guess we could do something like:
struct skb_frag_st
On Tue, Aug 08, 2006 at 04:39:15PM -0700, David Miller wrote:
>
> I'm beginning to think that where we store the
> skb_shared_info() is a weakness of the SKB design.
I'm not sure whether the problem is where we store skb_shared_info,
or the fact that we can't put kmalloc'ed memory into skb_shinfo
18 matches
Mail list logo
