All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Clouter <alex@digriz.org.uk>
To: david@lang.hm
Cc: linux-kernel@vger.kernel.org, sefi@s-e-f-i.de
Subject: Re: When does Linux drop UDP packets?
Date: Fri, 5 Jun 2009 20:29:34 +0100	[thread overview]
Message-ID: <20090605192933.GH2014@woodchuck> (raw)
In-Reply-To: <alpine.DEB.1.10.0906051214140.9159@asgard>

Hi,

* david@lang.hm <david@lang.hm> [2009-06-05 12:15:27-0700]:
> 
> On Fri, 5 Jun 2009, Alexander Clouter wrote:
> 
> > * david@lang.hm <david@lang.hm> [2009-06-04 16:19:56-0700]:
> > > 
> > > On Thu, 4 Jun 2009, Alexander Clouter wrote:
> > > >
> > > > It's dead easy to transmit and receive multicast traffic, broadcasting
> > > > network traffic is so 1980's :)
> > > 
> > > there is only a difference between multicast and broadcast traffic if you
> > > are spanning subnets.
> > > 
> > Well yes and no.  Broadcast traffic is *always* handled by the kernel as
> > only the kernel can tell if it is interested in it or not.  With
> > multicast the NIC is configured to only pass particular
> > Ethernet multicast packets up to the kernel.
> > 
> > By using broadcast traffic the load (okay, hardly a big problem
> > now-a-days) hits *all* the workstations on the subnet, with multicast,
> > only those interested in the traffic receive it.
> 
> true, but only for some NICs, and even those tend to have a fairly small  
> number of slots for the filters. past these limits the OS handles it all  
> just like broadcasts.
> 
I *think* only the early ones have a naff non-hashing based to filter 
multicast flows, could be wrong though.

Either way, as a packet pusher by day, I dream of the venduh's 
discovering that multicast can be used for device discovery rather than 
expecting everything to be on the same subnet :-/

In this day and age, using broadcast to do a job is just plain lazy and 
braindead.

Cheers

-- 
Alexander Clouter
.sigmonster says: Misuse may cause suffocation.

  reply	other threads:[~2009-06-05 19:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-04 14:53 When does Linux drop UDP packets? Philipp Reh
2009-06-04 15:57 ` Steven Rostedt
     [not found]   ` <20090604161015.GA17303@miyuki>
     [not found]     ` <alpine.DEB.2.00.0906041222450.14994@gandalf.stny.rr.com>
2009-06-04 16:34       ` Steven Rostedt
2009-06-04 16:57         ` Steven Rostedt
2009-06-04 17:46         ` Jaswinder Singh Rajput
2009-06-04 21:07           ` Steven Rostedt
2009-06-04 17:57   ` david
2009-06-04 18:44     ` Eric Dumazet
2009-06-04 18:49       ` david
2009-06-11 23:40   ` Nifty niftylinkern Mitch
2009-06-04 22:03 ` Alexander Clouter
2009-06-04 23:19   ` david
2009-06-05 19:10     ` Alexander Clouter
2009-06-05 19:15       ` david
2009-06-05 19:29         ` Alexander Clouter [this message]
2009-06-24  7:47     ` Herbert Xu
2009-06-25  4:32       ` david
2009-06-25  5:00         ` Herbert Xu
2009-06-25  5:37           ` david
2009-06-25  6:13             ` Herbert Xu
2009-06-25  7:38               ` Alexander Clouter

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=20090605192933.GH2014@woodchuck \
    --to=alex@digriz.org.uk \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sefi@s-e-f-i.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.