On Tue, Apr 25, 2006 at 07:29:40AM -0400, linux-os (Dick Johnson) wrote:
Message signaled interrupts are just a kudge to save a trace on a
PC board (read make junk cheaper still).
yes. Also in PCI-Express there is no physical interrupt line anymore due to
the architecture, so even
On Tuesday 02 May 2006 14:41, Vojtech Pavlik wrote:
You seem to be missing the fact that most of todays interrupts are
delivered through the APIC bus, which isn't fast at all.
You mean slow right? Modern x86s (anything newer than a P3) generally don't
have an separate APIC bus anymore but
On Mon, 24 Apr 2006, Auke Kok wrote:
linux-os (Dick Johnson) wrote:
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible.
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for cachelines from other cpus
too much.
Thats
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for
[EMAIL PROTECTED] wrote:
Subject: Re: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
MSI-X. with MSI you still have only one cpu handling all MSI interrupts and
that doesn't look any different than ordinary interrupts.
On Mon, 24 Apr 2006, Rick Jones wrote:
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
MSI-X. with MSI you still have only one cpu handling all MSI interrupts and
that doesn't
linux-os (Dick Johnson) wrote:
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt,
Ingo Oeser wrote:
Hi Jörn,
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer.
Hmm, for me the main point was to keep the
Hi Dave,
On Sunday, 23. April 2006 07:56, David S. Miller wrote:
If cacheline bouncing because of the shared filled_entries becomes an issue,
you are receiving or sending a lot.
Cacheline bouncing is the core issue being addressed by this
data structure, so we really can't consider your
On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
Going all the way to the socket is a large endeavor and will require a
lot of restructuring to do it right, so expect this to take on the
order of months.
That's what you said about Niagara too :-)
Good luck!
--
Hi Jörn,
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer.
Hmm, for me the main point was to keep the complete processing
of a single
On Sat, 22 April 2006 15:29:58 +0200, Ingo Oeser wrote:
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer.
Hmm, for me the main
On Fri, 21 April 2006 18:52:47 +0200, Ingo Oeser wrote:
What about sth. like
struct netchannel {
/* This is only read/written by the writer (producer) */
unsigned long write_ptr;
struct netchannel_buftrailer *netchan_queue[NET_CHANNEL_ENTRIES];
/* This is modified by both */
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for cachelines from other cpus
too much.
Thats right. This will
From: Ingo Oeser [EMAIL PROTECTED]
Date: Sun, 23 Apr 2006 02:05:32 +0200
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which
From: Jörn Engel [EMAIL PROTECTED]
Date: Sat, 22 Apr 2006 13:48:46 +0200
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer. Receiving and sending a lot can be expected to be the
common
From: bert hubert [EMAIL PROTECTED]
Date: Sat, 22 Apr 2006 21:30:24 +0200
On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
Going all the way to the socket is a large endeavor and will require a
lot of restructuring to do it right, so expect this to take on the
order of
From: Ingo Oeser [EMAIL PROTECTED]
Date: Sat, 22 Apr 2006 15:29:58 +0200
On Saturday, 22. April 2006 13:48, Jörn Engel wrote:
Unless I completely misunderstand something, one of the main points of
the netchannels if to have *zero* fields written to by both producer
and consumer.
Hmm,
From: Ingo Oeser [EMAIL PROTECTED]
Date: Fri, 21 Apr 2006 18:52:47 +0200
nice to see you getting started with it.
Thanks for reviewing.
I'm not sure about the queue logic there.
1867 /* Caller must have exclusive producer access to the netchannel. */
1868 int netchannel_enqueue(struct
Hi David,
nice to see you getting started with it.
I'm not sure about the queue logic there.
1867 /* Caller must have exclusive producer access to the netchannel. */
1868 int netchannel_enqueue(struct netchannel *np, struct netchannel_buftrailer
*bp)
1869 {
1870unsigned long tail;
1871
[ Maybe ask questions like this on netdev where the networking
developers hang out? Added to CC: ]
Van fell off the face of the planet after giving his presentation and
never published his code, only his slides.
I've started to make a slow attempt at implementing his ideas, nothing
but pure
23 matches
Mail list logo
