> "Werner" == Werner Almesberger <[EMAIL PROTECTED]> writes:
Werner> Jeff Garzik wrote:
>> 3) Slabbier packet allocation.
Werner> Hmm, this may actually be worse during bursts: if you burst
Werner> exceeds the preallocated size, you have to perform more
Werner> expensive/slower operations (e
> "Noah" == Noah Romer <[EMAIL PROTECTED]> writes:
Noah> In my experience, Tx interrupt mitigation is of little
Noah> benefit. I actually saw a performance increase of ~20% when I
Noah> turned off Tx interrupt mitigation in my driver (could have been
Noah> poor implementation on my part).
Yo
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> 1) Rx Skb recycling. It would be nice to have skbs returned to
Jeff> the driver after the net core is done with them, rather than
Jeff> have netif_rx free the skb. Many drivers pre-allocate a number
Jeff> of maximum-sized skbs into w
Hi!
> > an alloc of a PKT_BUF_SZ'd skb immediately follows a free of a
> > same-sized skb. 100% of the time.
>
> Free/Alloc gives the mm the chance to throttle it by failing, and also to
> recover from fragmentation by packing the slabs. If you don't do it you need
> to add a hook somewhere th
Hello!
> > 3) Enforce correct usage of it in all the networking :-)
>
> ,) -- the tricky part.
No tricks, IP[v6] is already enforced to be clever; all the rest are free
to do this, if they desire. And btw, driver need not to parse anything,
but its internal stuff and even aligning eth II header
"David S. Miller" wrote:
> Andi Kleen writes:
> > Or did I misunderstand you?
>
> What is wrong with making methods, keyed off of the ethernet protocol
> ID, that can do the "I know where/how-long headers are" stuff for that
> protocol? Only cards with the problem call into this function vector
Jeff Garzik writes:
> I only want to know if more are coming, not actually pass multiples..
Ok, then my only concern is that the path from "I know more is coming"
down to hard_start_xmit invocation is long. It would mean passing a
new piece of state a long distance inside the stack from SKB or
Andi Kleen writes:
> Or did I misunderstand you?
What is wrong with making methods, keyed off of the ethernet protocol
ID, that can do the "I know where/how-long headers are" stuff for that
protocol? Only cards with the problem call into this function vector
or however we arrange it, and then
"David S. Miller" wrote:
> Jeff Garzik writes:
> > 2) Tx packet grouping.
> ...
> > Disadvantages?
>
> See Torvalds vs. world discussion on this list about API entry points
> which pass multiple pages at a time versus simpler ones which pass
> only a single page at a time. :-)
I only want to
On Mon, Feb 26, 2001 at 03:48:31PM -0800, David S. Miller wrote:
>
> Andi Kleen writes:
> > 4) Better support for aligned RX by only copying the header
>
> Andi you can make this now:
>
> 1) Add new "post-header data pointer" field in SKB.
That would imply to let the drivers parse all headers
Andi Kleen writes:
> 4) Better support for aligned RX by only copying the header
Andi you can make this now:
1) Add new "post-header data pointer" field in SKB.
2) Change drivers to copy into aligned headroom as
you mention, and they set this new post-header
pointer as appropriate. For
Jeff Garzik writes:
> 1) Rx Skb recycling.
...
> Advantages: A de-allocation immediately followed by a reallocation is
> eliminated, less L1 cache pollution during interrupt handling.
> Potentially less DMA traffic between card and host.
...
> Disadvantages?
It simply cannot work, as Al
In message <[EMAIL PROTECTED]> you write:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> > Advantages: A de-allocation immediately followed by a reallocation is
> > eliminated, less L1 cache pollution during interrupt handling.
> > Potentially less DMA traffic between card and host.
> >
> > Dis
Andrew Morton wrote:
(kernel profile of TCP tx/rx)So, naively, the most which can be saved here by
optimising
> the skb and memory usage is 5% of networking load. (1% of
> system load @100 mbps)
>
For a local tx/rx. (open question) What happens with
a router box with netfilter and queueing? P
At 2:32 am + 25/2/2001, Jeremy Jackson wrote:
>Jeff Garzik wrote:
>
>(about optimizing kernel network code for busmastering NIC's)
>
>> Disclaimer: This is 2.5, repeat, 2.5 material.
>
>Related question: are there any 100Mbit NICs with cpu's onboard?
>Something mainstream/affordable?(i.e. not
Chris Wedgwood wrote:
> That said, it would be an extemely neat thing to do from a technical
> perspective, but I don't know if you would ever get really good
> performance from it.
Well, you'd have to re-design the networking code to support NUMA
architectures, with a fairly fine granularity. I'
Jeff Garzik wrote:
> 1) Rx Skb recycling.
Sounds like a potentially useful idea. To solve the most immediate memory
pressure problems, maybe VM could provide some function that does a kfree
in cases of memory shortage, and that does nothing otherwise, so the
driver could offer to free the skb aft
Jeff Garzik wrote:
>
>...
> 1) Rx Skb recycling.
>...
> 2) Tx packet grouping.
>...
> 3) Slabbier packet allocation.
Let's see what the profiler says. 10 seconds of TCP xmit
followed by 10 seconds of TCP receive. 100 mbits/sec.
Kernel 2.4.2+ZC.
c0119470 do_softirq
On Sat, 24 Feb 2001, Jeff Garzik wrote:
> Disclaimer: This is 2.5, repeat, 2.5 material.
[snip]
> 1) Rx Skb recycling. It would be nice to have skbs returned to the
> driver after the net core is done with them, rather than have netif_rx
> free the skb. Many drivers pre-allocate a number of m
Jeff Garzik wrote:
(about optimizing kernel network code for busmastering NIC's)
> Disclaimer: This is 2.5, repeat, 2.5 material.
Related question: are there any 100Mbit NICs with cpu's onboard?
Something mainstream/affordable?(i.e. not 1G ethernet)
Just recently someone posted asking some tec
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> 1) Rx Skb recycling. It would be nice to have skbs returned to the
Jeff> driver after the net core is done with them, rather than have netif_rx
Jeff> free the skb. Many drivers pre-allocate a number of maximum-sized skbs
On Sat, Feb 24, 2001 at 07:13:14PM -0500, Jeff Garzik wrote:
> Sorry... I should also point out that I was thinking of tulip
> architecture and similar architectures, where you have a fixed number of
> Skbs allocated at all times, and that number doesn't change for the
> lifetime of the driver.
>
Jeff Garzik wrote:
>
> Andi Kleen wrote:
> >
> > Jeff Garzik <[EMAIL PROTECTED]> writes:
> >
> > > Advantages: A de-allocation immediately followed by a reallocation is
> > > eliminated, less L1 cache pollution during interrupt handling.
> > > Potentially less DMA traffic between card and host.
On Sat, Feb 24, 2001 at 07:03:38PM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> >
> > Jeff Garzik <[EMAIL PROTECTED]> writes:
> >
> > > Advantages: A de-allocation immediately followed by a reallocation is
> > > eliminated, less L1 cache pollution during interrupt handling.
> > > Potentially
Andi Kleen wrote:
>
> Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> > Advantages: A de-allocation immediately followed by a reallocation is
> > eliminated, less L1 cache pollution during interrupt handling.
> > Potentially less DMA traffic between card and host.
> >
> > Disadvantages?
>
> You ne
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Advantages: A de-allocation immediately followed by a reallocation is
> eliminated, less L1 cache pollution during interrupt handling.
> Potentially less DMA traffic between card and host.
>
> Disadvantages?
You need a new mechanism to cope with low m
Disclaimer: This is 2.5, repeat, 2.5 material.
I've talked about the following items with a couple people on this list
in private. I wanted to bring these up again, to see if anyone has
comments on the following suggested netdevice changes for the upcoming
2.5 development series of kernels.
27 matches
Mail list logo
