Dave Hansen <[EMAIL PROTECTED]> wrote on 14.02.2008 18:12:43:
> On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> > Dave Hansen <[EMAIL PROTECTED]> wrote on 13.02.2008 18:05:00:
> > > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> >
most prominent example heading
there
>
> Do you know what other operating systems do with this hardware?
We're not aware of another open source Operating system trying to address
this topic.
>
> In the future, please make an effort to get review from knowledgeable
> people
Michael Ellerman wrote on 26.11.2007 09:16:28:
> Solutions that might be better:
>
> a) if there are a finite number of handles and we can predict their
> values, just delete them all in the kdump kernel before the driver
> loads.
Guessing the values does not work, because of the handle s
Michael Neuling <[EMAIL PROTECTED]> wrote on 03.11.2007 07:06:31:
> > DD allocates HEA resources and gets firmware_handles for these
resources.
> > To free the resources DD needs to use exactly these handles.
> > There's no generic firmware call "clean out all resources".
> > Allocating the same
Michael Ellerman <[EMAIL PROTECTED]> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broke
Michael Ellerman <[EMAIL PROTECTED]> wrote on 30.10.2007 23:50:36:
>
> On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> >
> > Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
> > Hope I didn't miss anything here...
>
>
Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
>
>
> How do you plan to support kdump?
>
When kexec is fully supported kdump should work out of the box
as for any other ethernet card (if you load the right eth driver).
There's nothing specific to kdump you have to handle in
e
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on 16.10.2007
11:01:49:
>
>
> Christoph, have any of you tried it on powerpc ?
No we didn't try this (yet).
This approach makes a lot of sense.
Why is this not installed by both large distros on PPC by default?
how mature is this for larger SMPs
the HEA device driver
alone.
It could also affect any other networking cards on POWER (e1000,s2io...).
Paul, Michael, Arndt, what is your opinion here?
Gruss / Regards
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ed to a different TCP receive side
processing?
In a perfect world we shouldn't see a diffference if this is enabled or
not,
but measurements indicate something completely different at 10gbit.
Gruss / Regards
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscrib
is it possible to figure out if this is what you want or just DoS?
It doesn't change anything compared to a non LRO driver, we process a
certain
maximum amount of frames before waiting for the next interrupt,
the packet filters/DoS should still see all traffic (which is above the
driver).
Any sugge
Andrew Morton <[EMAIL PROTECTED]> wrote on 27.10.2006 05:13:13:
> On Wed, 25 Oct 2006 13:11:42 +0200
> Jan-Bernd Themann <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes kzalloc parameters (GFP_ATOMIC instead of GFP_KERNEL)
>
> why?
these few kcallocs run in atomic context in some situations.
>
> Hi,
>
> > I asked SO to recount arguments and we've come to a conclusion that
> > there're in fact 19 args not 18 as the name suggests. 19 args is
> > I-N-S-A-N-E.
>
> It will be partially cleaned up by:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2006-July/024556.html
>
> However it doesnt f
> You should really do some measurements to see what the minimal
> queue sizes are that can get you optimal throughput.
>
>Arnd <><
we did.
And as always in performance tuning... one size fits all unfortunately is
not the correct answer.
Therefore we'll leave that open to the user as most othe
"Jenkins, Clive" wrote on 15.08.2006 12:53:05:
> > > You mean the eHEA has its own concept of page size? Separate from
> the
> > > page size used by the MMU?
> > >
> >
> > yes, the eHEA currently supports only 4K pages for queues
>
> In that case, I suggest use the kernel's page size, but add a
well, now I'm confused...
2 People, two opinions
Here's a URL for a complete tarball, "sharing" the download location with
our other driver.
http://prdownloads.sourceforge.net/ibmehcad/ehea_EHEA_0002.tgz
We're waiting for a sourceforge project now since 9 days to put out a tgz,
and it looks
n for example sourceforge?
Gruss / Regards . . . Christoph Raisch
christoph raisch, HCAD teamlead, IODF2 (d/3627), ibm boeblingen lab,
phone: (+49/0)7031-16 4584, fax: -16 2042, loc: 71032-05-003, internet:
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netd
17 matches
Mail list logo
