From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Ingo Oeser <netdev@axxeo.de>
Cc: "David S. Miller" <davem@davemloft.net>,
simlo@phys.au.dk, linux-kernel@vger.kernel.org, mingo@elte.hu,
netdev@vger.kernel.org, Ingo Oeser <ioe-lkml@rameria.de>
Subject: Re: Van Jacobson's net channels and real-time
Date: Sat, 22 Apr 2006 13:48:46 +0200 [thread overview]
Message-ID: <20060422114846.GA6629@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200604211852.47335.netdev@axxeo.de>
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 */
> atomic_t filled_entries; /* cache_line_align this? */
>
> /* This is only read/written by the reader (consumer) */
> unsigned long read_ptr;
> }
>
> This would prevent this bug from the beginning and let us still use the
> full queue size.
>
> If cacheline bouncing because of the shared filled_entries becomes an issue,
> you are receiving or sending a lot.
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 case, so taking a performance hit in this case is hardly a good
idea.
I haven't looked at Davem's implementation at all, but Van simply
seperated fields in consumer-written and producer-written, with proper
alignment between them. Some consumer-written fields are also read by
the producer and vice versa. But none of this results in cacheline
pingpong.
If your description of the problem is correct, it should only mean
that the implementation has a problem, not the concept.
Jörn
--
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt
next prev parent reply other threads:[~2006-04-22 20:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-20 16:29 Esben Nielsen
2006-04-20 19:09 ` David S. Miller
2006-04-21 16:52 ` Ingo Oeser
2006-04-22 11:48 ` Jörn Engel [this message]
2006-04-22 13:29 ` Ingo Oeser
2006-04-22 13:49 ` Jörn Engel
2006-04-23 0:05 ` Ingo Oeser
2006-04-23 5:50 ` David S. Miller
2006-04-24 16:42 ` Auke Kok
2006-04-24 16:59 ` linux-os (Dick Johnson)
2006-04-24 17:19 ` Rick Jones
2006-04-24 18:12 ` linux-os (Dick Johnson)
2006-04-24 23:17 ` Michael Chan
2006-04-25 1:49 ` Auke Kok
2006-04-25 11:29 ` linux-os (Dick Johnson)
2006-05-02 12:41 ` Vojtech Pavlik
2006-05-02 15:58 ` Andi Kleen
2006-04-23 5:52 ` David S. Miller
2006-04-23 9:23 ` Avi Kivity
2006-04-23 5:51 ` David S. Miller
2006-04-23 5:56 ` David S. Miller
2006-04-23 14:15 ` Ingo Oeser
2006-04-22 19:30 ` bert hubert
2006-04-23 5:53 ` David S. Miller
2006-04-21 8:53 ` Jan Kiszka
2006-04-24 14:22 ` Esben Nielsen
2006-04-27 8:09 ` Jan Kiszka
2006-04-27 8:16 ` David S. Miller
2006-04-27 10:00 ` Jan Kiszka
2006-04-27 19:50 ` David S. Miller
[not found] <63KcN-6lD-25@gated-at.bofh.it>
[not found] ` <64wrg-2cg-41@gated-at.bofh.it>
[not found] ` <64wAE-2Cs-9@gated-at.bofh.it>
[not found] ` <64AkV-8cG-7@gated-at.bofh.it>
[not found] ` <65cqo-5tR-33@gated-at.bofh.it>
[not found] ` <65cJF-66i-11@gated-at.bofh.it>
2006-04-24 23:48 ` Robert Hancock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060422114846.GA6629@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=davem@davemloft.net \
--cc=ioe-lkml@rameria.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@axxeo.de \
--cc=netdev@vger.kernel.org \
--cc=simlo@phys.au.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome