From: Nivedita Singhvi <niv@us.ibm.com>
To: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Cc: netdev <netdev@vger.kernel.org>,
David Stevens <dlstevens@us.ibm.com>,
Christoph Lameter <cl@linux.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] Multicast socket option
Date: Fri, 29 May 2009 07:21:21 -0700 [thread overview]
Message-ID: <4A1FEF61.9090005@us.ibm.com> (raw)
In-Reply-To: <200905290925.19155.remi.denis-courmont@nokia.com>
Rémi Denis-Courmont wrote:
>> In this case, default behaviour is _unchanged_ from the current
>> Linux standard. The socket option is set by default to provide
>> original behaviour. Sockets wishing to receive data only from
>> multicast groups they join explicitly will need to clear this
>> socket option.
>
> You can already achieve this by checking the destination address in the
> SOL_PKTINFO ancilliary data. Sure, it will cause extra context switches to
> process unwanted packets but it will work with any kernel version.
>
True, and depending on your environment and workload, this
is a non-event or a big deal. For low latency, real time
and other performance-sensitive applications, this can be
an issue. Think lots (hundreds of threads, perhaps) listening
on different channels(groups). They will likely all get
woken, scheduled, possibly preempt running lower-priority
tasks to process this delivery that they don't need. Seen
across the system, the delivery by the kernel of packets
to user space processes which don't want them can be very
significant overhead (context switches, scheduling out/in,...).
thanks,
Nivedita
next prev parent reply other threads:[~2009-05-29 14:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-28 17:00 [PATCH] Multicast socket option Nivedita Singhvi
2009-05-29 6:25 ` Rémi Denis-Courmont
2009-05-29 14:21 ` Nivedita Singhvi [this message]
2009-05-29 10:35 ` Neil Horman
2009-05-29 14:12 ` Christoph Lameter
2009-05-29 15:06 ` Nivedita Singhvi
2009-06-02 7:45 ` David Miller
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=4A1FEF61.9090005@us.ibm.com \
--to=niv@us.ibm.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=remi.denis-courmont@nokia.com \
/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).