9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] Multicast example
Date: Wed, 23 Jun 2010 08:55:08 -0400	[thread overview]
Message-ID: <c207c8144dfaf41308e338fb593eb869@kw.quanstro.net> (raw)
In-Reply-To: <AANLkTilvMtJ70q_xwMPB5N2ATqTFQxTy9rl-Y1nnrsSy@mail.gmail.com>

> However, I'm not quite sure about receiving.
> I see an "addmulti" in ip(3) but I don't quite understand the comment
> and I couldn't penetrate the source.

what comment?  unfortunately, where ip(3) says
"media address", i think it really means ip address.
the code says it accepts
	addmulti $rxaddr $multiaddr
or
	addmulti $multiaddr	# assume $rxaddr = normal rec. addr

ip(3) is quite unclear (to me, anyway) about the
differences between the ip stack's notions and
the interface' notions.  perhaps i notice because
we send a lot of non-ip traffic.

in the case of multicast mac addresses, ip tries to
bridge the gap.  but i don't think that current hardware
works this way.  modern hardware tends to hash
multicast *ethernet* addresses, but not ip addresses.
and that's the way that addmulti/remmulti are implemented
in netif.c and /sys/src/9/pc/ether[a-z]*.c:/^[a-z0-9]+multicast

mind the gap!

also for mtu, ip assumes that it is fixed per medium,
and not per hardware device. this bit from ip(3) is misleading.

- The
- .I mtu
- is the size in bytes of the largest packet that this interface can send.

the mtu for ip(3) is the largest packet that ip tries to send.
this may be larger (that is, misconfigured), smaller or the same
as the interface mtu.  in 9atom, the interface mtu may be
set by
	echo mtu 9000 > /net/ether0/clone
and the /net/ether0/mtu file has the mintu mtu and maxtu.

i have been meaning to let ip discover the current mtu
by reading it from the device, but i need a solution that will
keep the mtu high for aoe even if ip wants it at 1514 to allow
ip to make sure that its idea of the interface (media) mtu
isn't wrong.  i'm also somewhat uncomfortable with managing
the interface via an ip proxy.

we routinely mix 8228-byte aoe packets with 1514-byte ip
packets.  the interface's mtu is set to 9000, while the ip stack's
mtu is set to 1514.

to sum up, i think there is a little confusion in the code.
i'd be interested in your results.

- erik



      reply	other threads:[~2010-06-23 12:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-23  5:05 Justin Wilson
2010-06-23 12:55 ` erik quanstrom [this message]

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=c207c8144dfaf41308e338fb593eb869@kw.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /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).