From: Patrick McHardy <kaber@trash.net>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: netdev <netdev@vger.kernel.org>, jamal <hadi@cyberus.ca>,
Thomas Graf <tgraf@suug.ch>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: multicasting netlink messages to groups > 31 from userspace
Date: Wed, 04 Jul 2007 16:48:07 +0200 [thread overview]
Message-ID: <468BB327.5050709@trash.net> (raw)
In-Reply-To: <1183559883.3812.42.camel@johannes.berg>
Johannes Berg wrote:
> On Wed, 2007-07-04 at 16:30 +0200, Patrick McHardy wrote:
>
>>I wonder if thats really a good idea to use multicast for device
>>configuration. Unicast transmissions from userspace to kernel
>>are reliable when you don't use MSG_DONTWAIT. For multicasts
>>doing the same would mean blocking on each receiver when the
>>receive queue is full.
>
>
> That's a good point actually. Are transmissions from userspace to
> userspace also reliable in that case?
Yes, although in both cases you have no guarantee how long its
going to take, someone else could be flooding the receive queue.
For userspace this is more likely to be a real problem though
since the kernel will keep processing the queue as long as packets
are in it, while userspace could be scheduled away.
> In fact, we haven't quite decided yet whether we want all configuration
> to be via netlink. I strongly prefer this, but other people say that
> userspace<->userspace communication is nothing that nl80211 should be
> involved in.
I'm not so sure myself whether netlink is really a good idea for
userspace<->userspace communication because of the above reason.
IIRC Herbert had the same doubts some time ago, I wonder what
made him change his mind.
> What I initially wanted was to publish something like "Device wlan0 is
> managed by netlink pid 12345" (or 0 if the kernel is doing it) and then
> configuration would be "send to <number the kernel told you>". However,
> that got me into problems when trying to determine "is the process
> owning netlink pid 12345 still alive" at which point Herbert suggested
> the use of multicast groups (and doing the exclusion "only one manager
> per netdev" in userspace instead of the kernel).
There is a notifier for userspace unicast socket releases, would adding
another one for multicast groups help?
next prev parent reply other threads:[~2007-07-04 14:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-03 19:51 multicasting netlink messages to groups > 31 from userspace Johannes Berg
2007-07-04 12:04 ` Evgeniy Polyakov
2007-07-04 13:54 ` Johannes Berg
2007-07-04 14:12 ` Patrick McHardy
2007-07-04 14:18 ` Johannes Berg
2007-07-04 14:30 ` Patrick McHardy
2007-07-04 14:38 ` Johannes Berg
2007-07-04 14:48 ` Patrick McHardy [this message]
2007-07-04 14:56 ` Johannes Berg
2007-07-04 15:00 ` Patrick McHardy
2007-07-04 15:08 ` Johannes Berg
2007-07-05 13:37 ` Patrick McHardy
2007-07-06 10:53 ` Johannes Berg
2007-07-06 15:08 ` jamal
2007-07-05 13:53 ` jamal
2007-07-05 14:08 ` Patrick McHardy
2007-07-06 10:50 ` Johannes Berg
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=468BB327.5050709@trash.net \
--to=kaber@trash.net \
--cc=hadi@cyberus.ca \
--cc=herbert@gondor.apana.org.au \
--cc=johannes@sipsolutions.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/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;
as well as URLs for NNTP newsgroup(s).