On Sat, Aug 05, 2006 at 08:33:07PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Sat, Aug 05, 2006 at 02:24:36PM +0400, Evgeniy Polyakov wrote:
> >
> > > If we had a flag to indicate writability we could also have a flag to
> > > indicate that the memory comes from kmalloc rather than alloc_pag
On Sat, Aug 05, 2006 at 02:24:36PM +0400, Evgeniy Polyakov wrote:
>
> > If we had a flag to indicate writability we could also have a flag to
> > indicate that the memory comes from kmalloc rather than alloc_page.
>
> Yes, that would be good, but who will give us a bit in the struct page?
> Can we
On Sat, Aug 05, 2006 at 08:09:54PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> > If you can create several skbs and link them togeter you defenitely can
> > organize pages into frag_list, just get pages from different skb->data
> > and free those skbs.
>
> Having a more flexible mechanism for m
On Sat, Aug 05, 2006 at 01:58:46PM +0400, Evgeniy Polyakov wrote:
>
> If you can create several skbs and link them togeter you defenitely can
> organize pages into frag_list, just get pages from different skb->data
> and free those skbs.
Having a more flexible mechanism for managing skb_shared_inf
On Fri, Aug 04, 2006 at 02:02:51PM -0700, Jesse Brandeburg ([EMAIL PROTECTED])
wrote:
> >> So how many skb allocation schemes do you code into a single driver?
> >> Kmalloc everything, page alloc everything, combination of kmalloc and
> >> page buffers for hardware that does header split? That's
On 8/4/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Fri, Aug 04, 2006 at 08:34:46AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> So how many skb allocation schemes do you code into a single driver?
> Kmalloc everything, page alloc everything, combination of kmalloc and
> page buffers for
On Fri, Aug 04, 2006 at 08:34:46AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> So how many skb allocation schemes do you code into a single driver?
> Kmalloc everything, page alloc everything, combination of kmalloc and
> page buffers for hardware that does header split? That's three
> version
On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Fri, Aug 04, 2006 at 03:59:37PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Interesting. Could you guys post figures on alloc_page speed vs. kmalloc?
They probalby measured kmalloc cache access, which only falls to
alloc_pages when ca
On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> You're changing the size of the buffer without telling the hardware.
> In the interrupt context e1000 knows the size of what was DMAed into
> the skb, but that's after the fact. So e1000 could detect that memory
> was corrupted, but not pr
On Thu, Aug 03, 2006 at 01:32:10PM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> >Maximum e1000 frame is 16128 bytes, which is enough before being rounded
> >to 16k to have a space for shared info.
> >My patch just tricks refilling logic to request to allocate slightly less
> >than was setup when
On Fri, Aug 04, 2006 at 03:59:37PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Chris Leech <[EMAIL PROTECTED]> wrote:
> >
> > We could try and only use page allocations for older e1000 devices,
> > putting headers and payload into skb->frags and copying the headers
> > out into the skb->data ar
On Thu, Aug 03, 2006 at 10:55:01PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Fri, 04 Aug 2006 15:52:40 +1000
>
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > But it does not support splitting them into page sized chunks, so it
> >
Chris Leech <[EMAIL PROTECTED]> wrote:
>
> We could try and only use page allocations for older e1000 devices,
> putting headers and payload into skb->frags and copying the headers
> out into the skb->data area as needed for processing. That would do
> away with large allocations, but in Jesse's
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> But it does not support splitting them into page sized chunks, so it
> requires the whole jumbo frame allocation in one contiguous chunk, 9k
> will be transferred into 16k allocation (order 3), since SLAB uses
> power-of-2 allocation.
Actually order
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 04 Aug 2006 15:52:40 +1000
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > But it does not support splitting them into page sized chunks, so it
> > requires the whole jumbo frame allocation in one contiguous chunk, 9k
> > will be transferred i
Evgeniy Polyakov wrote:
> On Thu, Aug 03, 2006 at 08:09:07PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
> wrote:
>> Evgeniy Polyakov schrieb:
>>> On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
>>> PROTECTED]) wrote:
>> then skb_alloc adds a little
>> (sizeof(struct skb_
Maximum e1000 frame is 16128 bytes, which is enough before being rounded
to 16k to have a space for shared info.
My patch just tricks refilling logic to request to allocate slightly less
than was setup when mtu was changed.
The maximum supported MTU size differs between e1000 devices due to
diff
On 8/3/06, Arnd Hannemann <[EMAIL PROTECTED]> wrote:
Well you say "if a single buffer per frame is going to be used". Well,
if I understood you correctly i could set the MTU to, lets say 4000.
Then the driver would enable the "jumbo frame bit" of the hardware, and
allocate only a 4k rx buffer, ri
On Thu, Aug 03, 2006 at 08:09:07PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov schrieb:
> > On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> then skb_alloc adds a little
> (sizeof(struct skb_shared_info)) at the end, and
Evgeniy Polyakov schrieb:
> On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
then skb_alloc adds a little
(sizeof(struct skb_shared_info)) at the end, and this ends up
in 32k request just for 9k jumbo frame.
>>> Strange, why this skb_shared_inf
Chris Leech schrieb:
> On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
>> > Strange, why this skb_shared_info cannon be added before first
>> alignment?
>> > And what about smaller frames like 1500, does this driver behave
>> similar
>> > (first align then add)?
>>
>> It can be.
>> Could
On Thu, Aug 03, 2006 at 08:57:36AM -0700, Chris Leech ([EMAIL PROTECTED]) wrote:
> On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >> Strange, why this skb_shared_info cannon be added before first alignment?
> >> And what about smaller frames like 1500, does this driver behave similar
>
On 8/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Strange, why this skb_shared_info cannon be added before first alignment?
> And what about smaller frames like 1500, does this driver behave similar
> (first align then add)?
It can be.
Could attached (completely untested) patch help?
On Thu, Aug 03, 2006 at 05:37:41PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
wrote:
> > It can be.
> > Could attached (completely untested) patch help?
>
> I will try this in a minute. However is there any way to see which
> allocation e1000 does without triggering allocation failures? ;-)
One
On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > >then skb_alloc adds a little
> > >(sizeof(struct skb_shared_info)) at the end, and this ends up
> > >in 32k request just for 9k jumbo frame.
> >
> > Strange, why this skb_shared_info cannon be added before
Evgeniy Polyakov wrote:
> On Thu, Aug 03, 2006 at 05:08:51PM +0200, Krzysztof Oledzki ([EMAIL
> PROTECTED]) wrote:
Why? After your explanation that makes sense for me. The driver needs
one contiguous chunk for those 9k packet buffer and thus requests a
3-order page of 16k. Or do i
Benjamin LaHaise schrieb:
> On Thu, Aug 03, 2006 at 03:48:39PM +0200, Arnd Hannemann wrote:
>> However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 GB of swap
>> enabled, so there should be plenty of memory available. HIGHMEM support
>> is off. The e1000 nic seems to be an 82540EM, which t
On Thu, Aug 03, 2006 at 05:08:51PM +0200, Krzysztof Oledzki ([EMAIL PROTECTED])
wrote:
> >then skb_alloc adds a little
> >(sizeof(struct skb_shared_info)) at the end, and this ends up
> >in 32k request just for 9k jumbo frame.
>
> Strange, why this skb_shared_info cannon be added before first ali
On Thu, Aug 03, 2006 at 05:08:51PM +0200, Krzysztof Oledzki ([EMAIL PROTECTED])
wrote:
> >>Why? After your explanation that makes sense for me. The driver needs
> >>one contiguous chunk for those 9k packet buffer and thus requests a
> >>3-order page of 16k. Or do i still do not understand this?
>
On Thu, 3 Aug 2006, Evgeniy Polyakov wrote:
Why? After your explanation that makes sense for me. The driver needs
one contiguous chunk for those 9k packet buffer and thus requests a
3-order page of 16k. Or do i still do not understand this?
Correct, except that it wants 32k.
e1000 logic is f
On Thu, 3 Aug 2006, Benjamin LaHaise wrote:
On Thu, Aug 03, 2006 at 04:49:15PM +0200, Krzysztof Oledzki wrote:
With 1 GB of RAM full 1GB/3GB (CONFIG_VMSPLIT_3G_OPT) seems to be
enough...
Nope, you lose ~128MB of RAM for vmalloc space.
No sure:
Linux version 2.6.17.7 ([EMAIL PROTECTED]) (
On Thu, Aug 03, 2006 at 04:37:35PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
wrote:
> >> im running vanilla 2.6.17.6 and if i try to set the mtu of my e1000 nic
> >> to 9000 bytes, page allocation failures occur (see below).
> >>
> >> However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 G
On Thu, 3 Aug 2006, Benjamin LaHaise wrote:
On Thu, Aug 03, 2006 at 03:48:39PM +0200, Arnd Hannemann wrote:
However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 GB of swap
enabled, so there should be plenty of memory available. HIGHMEM support
is off. The e1000 nic seems to be an 825
On Thu, Aug 03, 2006 at 04:49:15PM +0200, Krzysztof Oledzki wrote:
> With 1 GB of RAM full 1GB/3GB (CONFIG_VMSPLIT_3G_OPT) seems to be
> enough...
Nope, you lose ~128MB of RAM for vmalloc space.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Ema
Hi,
Evgeniy Polyakov wrote:
> On Thu, Aug 03, 2006 at 03:48:39PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
> wrote:
>> Hi,
>>
>> im running vanilla 2.6.17.6 and if i try to set the mtu of my e1000 nic
>> to 9000 bytes, page allocation failures occur (see below).
>>
>> However the box is a VIA Epi
On Thu, Aug 03, 2006 at 03:48:39PM +0200, Arnd Hannemann wrote:
> However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 GB of swap
> enabled, so there should be plenty of memory available. HIGHMEM support
> is off. The e1000 nic seems to be an 82540EM, which to my knowledge
> should support
On Thu, Aug 03, 2006 at 03:48:39PM +0200, Arnd Hannemann ([EMAIL PROTECTED])
wrote:
> Hi,
>
> im running vanilla 2.6.17.6 and if i try to set the mtu of my e1000 nic
> to 9000 bytes, page allocation failures occur (see below).
>
> However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 GB
Hi,
im running vanilla 2.6.17.6 and if i try to set the mtu of my e1000 nic
to 9000 bytes, page allocation failures occur (see below).
However the box is a VIA Epia MII12000 with 1 GB of Ram and 1 GB of swap
enabled, so there should be plenty of memory available. HIGHMEM support
is off. The e1000
38 matches
Mail list logo
