From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for
Date: Tue, 16 Dec 2008 11:19:08 +0000 [thread overview]
Message-ID: <20081216111908.GI14518@ghostprotocols.net> (raw)
In-Reply-To: <1229175685-18716-3-git-send-email-gerrit@erg.abdn.ac.uk>
Em Tue, Dec 16, 2008 at 01:40:45AM -0800, David Miller escreveu:
> From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> Date: Tue, 16 Dec 2008 06:29:54 +0100
>
> > | Hence I think we have a chance by going completely lockless here, by
> > | loading all configured CCIDs at runtime. In this manner the per-connection
> > | check "are all advertised CCIDs are loaded?" falls under the table, we
> > | do not need to worry about concurrent access, and loading DCCP implies that
> > | all needed CCIDs are there.
> > Unfortunately this won't work since the CCIDs depend on dccp.ko being
> > fully loaded, so requiring that CCID module are loaded during the
> > loading process of dccp.ko creates a cyclic dependency.
>
> I don't like this stuff at all.
>
> Every new connection you're going to loop over the CCID
> table and grab that CCID read lock N times.
>
> The first time it will do something meaningful, and then
> %99.999999999999 of subsequent calls will do nothing.
>
> What kind of overhead is deserved by that access pattern?
>
> And, if the first thing the first connection is going to do
> is load all the modules, there is ZERO reason to make them
> modular. It's just useless seperation and it adds all of
> this rediculious synchronization.
>
> If it's modular "for the sake of development" I'm sure you
> can simply reload the dccp.ko module when you make some
> CCID algorithm change.
>
> I'm tossing this patch set until we get something better
> in this area.
I guess that looking at tcp_set_congestion_control() could be a good
start. 8-)
- Arnaldo
next prev parent reply other threads:[~2008-12-16 11:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-13 13:41 [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for negotiation Gerrit Renker
2008-12-13 13:55 ` Michał Mirosław
2008-12-13 14:56 ` [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for Gerrit Renker
2008-12-14 14:50 ` [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for negotiation Michał Mirosław
2008-12-15 13:48 ` [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for Arnaldo Carvalho de Melo
2008-12-15 16:25 ` gerrit
2008-12-16 5:29 ` Gerrit Renker
2008-12-16 5:44 ` Gerrit Renker
2008-12-16 5:55 ` Gerrit Renker
2008-12-16 9:40 ` David Miller
2008-12-16 11:19 ` Arnaldo Carvalho de Melo [this message]
2008-12-16 11:31 ` [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for negotiation Michał Mirosław
2008-12-16 21:32 ` [PATCH 2/5] dccp: Auto-load (when supported) CCID plugins for David Miller
2008-12-16 22:25 ` Arnaldo Carvalho de Melo
2008-12-16 23:11 ` David Miller
2008-12-17 13:13 ` Arnaldo Carvalho de Melo
2008-12-18 5:46 ` Gerrit Renker
2008-12-18 5:56 ` Gerrit Renker
2008-12-18 14:01 ` Arnaldo Carvalho de Melo
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=20081216111908.GI14518@ghostprotocols.net \
--to=acme@redhat.com \
--cc=dccp@vger.kernel.org \
/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