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 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
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 bottl
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,
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 an
[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. An
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. M
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 wa
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 r
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
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 complet
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(stru
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
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.
>
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: 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, wh
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 wil
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 bo
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
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 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!
--
http://www.
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
1872
[ 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