netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: stephan.gatzka@gmail.com
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
	netdev <netdev@vger.kernel.org>,
	linux1394-devel@lists.sourceforge.net,
	Miller <davem@davemloft.net>,
	David
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
Date: Mon, 21 Jan 2013 08:39:57 +0100	[thread overview]
Message-ID: <20130121083957.6e2c5a68@stein> (raw)
In-Reply-To: <50FCDF5D.3060300@gmail.com>

On Jan 21 Stephan Gatzka wrote:
> > We could have multiple "net_device"s per single physical
> > interface at the same time, then.
> 
> Of course, but I would avoid it if it's not necessary. What's the 
> problem with introducing a function pointer in struct net_device or 
> struct net_device_ops?

Two net_device instances on one 1394 card would be awkward:  They would
have to share one instance of isochronous reception context (for reception
of asynchronous 1394 streams; those are used for broadcasts and
multicasts).  Such a sharing is surely possible, but if double net_device
instantiation can be avoided, then avoid it.

Not to mention the user interface problem of having two netifs, one which
only supports IPv4 and another one which only supports IPv6.  So far I
never had IPv6 configured into a Linux kernel, but I suppose that folks
are used to be able to use eth0 etc. for both protocols.

> > Multicast is a big issue.  Because IPv6 is fan of
> > multicast, and it uses link-local multicast as its
> > core infrastructure.  Without infrastructure to
> > support it, I'm not going to agree.
> 
> firewire net supports multicast and we use it very often. My patch to 
> support IPv6 does not change it. In fact, because I can communicate via 
> IPv6  between two firewire nodes, multicast _is_ running. The driver 
> does not do lot's of special things with multicast packets. But 
> multicast packets are recognized because they have to be sent somehow 
> different (GASP).

(At the moment we transport multicasts to the same 1394 channel like
broadcasts.

IEEE 1394 supports two addressing modes:  IEEE 1212 based memory-mapable
addresses of the form bus:node:offset = 10 bits + 6 bits + 48 bits for
node-to-node communication, and "channel" = a 6 bit channel number for
communication of 1 node to 0...n nodes.

RFC 2734 broadcasts and multicasts use the channel addressing type.  Hence
max_rec/ sspd/ unicast_FIFO come not into play with broadcasts and
multicasts.  Broadcasts are sent to a fixed known channel number;
multicasts are sent either to the broadcast channel number or to a
separate channel number which is negotiated per multicast group using RFC
2734 Multicast Channel Allocation Protocol.  For the time being the Linux
driver only implements multicasts to the broadcast channel.)
-- 
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412

  reply	other threads:[~2013-01-21  7:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 17:52 [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information Stephan Gatzka
2013-01-20 18:47 ` YOSHIFUJI Hideaki
2013-01-20 21:23   ` Stephan Gatzka
2013-01-21  2:29     ` YOSHIFUJI Hideaki
2013-01-21  6:25       ` Stephan Gatzka
2013-01-21  7:39         ` Stefan Richter [this message]
2013-01-21 11:50           ` YOSHIFUJI Hideaki
2013-01-21 19:25           ` Stephan Gatzka
2013-01-21 19:57             ` YOSHIFUJI Hideaki
2013-01-21 21:16               ` Stephan Gatzka
2013-01-27 14:43                 ` Stefan Richter
2013-01-27 17:21                   ` Stephan Gatzka
2013-01-27 18:20                     ` Stephan Gatzka
2013-01-27 18:25                       ` YOSHIFUJI Hideaki
2013-01-27 19:28                     ` YOSHIFUJI Hideaki
2013-01-27 23:26                       ` Stefan Richter
2013-01-21 11:50         ` YOSHIFUJI Hideaki
2013-01-21  8:09     ` Stefan Richter
2013-01-21 12:04       ` YOSHIFUJI Hideaki
2013-01-21 13:15         ` Stefan Richter
2013-01-21  6:37   ` Stephan Gatzka
2013-01-21 12:16     ` YOSHIFUJI Hideaki
2013-01-20 21:22 ` Waskiewicz Jr, Peter P
2013-01-21  6:17   ` Stephan Gatzka
2013-01-21  8:28     ` Stefan Richter
2013-01-21 12:32       ` YOSHIFUJI Hideaki
2013-01-21 14:15         ` YOSHIFUJI Hideaki

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=20130121083957.6e2c5a68@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=davem@davemloft.net \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephan.gatzka@gmail.com \
    --cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).