[RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

I've implemented IPv6 over firewire. Right now I'm facing the problem 
that the corresponding RFC3146 requires very firewire specific 
information sent during neighborhood discovery.

There was already a discussion on the linux1394 mailing list 
(http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and 
http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel) 


During that discussion all participants agreed that it makes no sense to 
introduce a dependency between the ndisc code and the firewire net driver.

So the most appealing option seems to be to introduce on more callback 
routine either in struct net_device or struct net_device_ops:

int (*ndo_fill_llao)(void *llao);

Because I'm not so familiar with the structure of the whole network 
infrastructure in Linux, I need some advice if struct net_device or 
struct net_device_ops is the right place.

Maybe it's worth to generalize this and do the same for IPv4/ARP because 
right now the ARP packets are mangled in the firewire net driver.

Nevertheless, I've to admit that right now it seems that only IPv6 over 
firewire requires such a callback routine.


Regards,

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> I've implemented IPv6 over firewire. Right now I'm facing the problem that the corresponding RFC3146 requires very firewire specific information sent during neighborhood discovery.
> 
> There was already a discussion on the linux1394 mailing list (http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel)
> 
> During that discussion all participants agreed that it makes no sense to introduce a dependency between the ndisc code and the firewire net driver.
> 
> So the most appealing option seems to be to introduce on more callback routine either in struct net_device or struct net_device_ops:
> 
> int (*ndo_fill_llao)(void *llao);
> 
> Because I'm not so familiar with the structure of the whole network infrastructure in Linux, I need some advice if struct net_device or struct net_device_ops is the right place.
> 
> Maybe it's worth to generalize this and do the same for IPv4/ARP because right now the ARP packets are mangled in the firewire net driver.
> 
> Nevertheless, I've to admit that right now it seems that only IPv6 over firewire requires such a callback routine.

My current position is to change "mac address" to

struct fwnet_hwaddr {
	u8	guid[8];
	u8	max_rec;
	u8	sspd;
	u8	fifo[6];
};

Benefits:

[ARP and NDISC]
- both can be handled in more natural way.
-- You will not need to mangle those packets when
   sending/receiving.
-- You do not need to inspect ARP/NDISC packet.
   By using netevent notification mechanism, you can
   learn peer parameters.
-- IP layer is not required to change very much.

[Multicast]
-it can be handled in more natural way.
-- MCAP (Multicast Channel Allocation Protocol) needs to
   know full IP multicast address.
-- We have IP multicast address => "hardware address"
   mapping for each L2 type in IP layer.
-- We expect that IP layer can request net_device to
   receive multicast stream for some multicast address
   via corresponding "hardware address".
-- This means that we need to have "hardware address"
   of 128bits (16 octets) or more.
-- By increasing size of dev->dev_addr, we can embedded
   full IPv6 address in it.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Waskiewicz Jr, Peter P]

On Sun, Jan 20, 2013 at 06:52:36PM +0100, Stephan Gatzka wrote:
> I've implemented IPv6 over firewire. Right now I'm facing the
> problem that the corresponding RFC3146 requires very firewire
> specific information sent during neighborhood discovery.
> 
> There was already a discussion on the linux1394 mailing list
> (http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel)
> 
> 
> During that discussion all participants agreed that it makes no
> sense to introduce a dependency between the ndisc code and the
> firewire net driver.
> 
> So the most appealing option seems to be to introduce on more
> callback routine either in struct net_device or struct
> net_device_ops:
> 
> int (*ndo_fill_llao)(void *llao);
> 
> Because I'm not so familiar with the structure of the whole network
> infrastructure in Linux, I need some advice if struct net_device or
> struct net_device_ops is the right place.
> 
> Maybe it's worth to generalize this and do the same for IPv4/ARP
> because right now the ARP packets are mangled in the firewire net
> driver.
> 
> Nevertheless, I've to admit that right now it seems that only IPv6
> over firewire requires such a callback routine.

I'm no expert on firewire requirements, but if you go down the path
of adding a net_device_ops member, I'd recommend adding a pointer
to your own struct of ops.  This would be similar to wireless ops.

Only a suggestion, since you may still need to add more ops later
on, and this way you can contain the inflation to a firewire-specific
struct of function pointers.

Cheers,
-PJ

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:

> My current position is to change "mac address" to
>
> struct fwnet_hwaddr {
> 	u8	guid[8];
> 	u8	max_rec;
> 	u8	sspd;
> 	u8	fifo[6];
> };
>

That is something I'm not really convinced of. As Stefan Richter pointed 
out clearly, the fifo address might be different between IPv4 and IPv6 
communication.

Stephan

------------------------------------------------------------------------------
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
> 
>> My current position is to change "mac address" to
>>
>> struct fwnet_hwaddr {
>>     u8    guid[8];
>>     u8    max_rec;
>>     u8    sspd;
>>     u8    fifo[6];
>> };
>>
> 
> That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.

We could have multiple "net_device"s per single physical
interface at the same time, then.

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.

And, firewire driver does not seem to support zerocopy
(fragmented skb) support.  It help performance.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

> I'm no expert on firewire requirements, but if you go down the path
> of adding a net_device_ops member, I'd recommend adding a pointer
> to your own struct of ops.  This would be similar to wireless ops.
>
> Only a suggestion, since you may still need to add more ops later
> on, and this way you can contain the inflation to a firewire-specific
> struct of function pointers.
>

Thanks for your note. Right now I only need on function pointer for 
filling RFC3146 information and I can imagine doing the same for 
IPv4/ARP which would be a second function.

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

> 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?

>
> 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).

>
> And, firewire driver does not seem to support zerocopy
> (fragmented skb) support.  It help performance.

O.k., good point. I will have a look into that. But I suggest to not mix 
up this issue with the IPv6 over firewire enhancement. That should be a 
separate patch.

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

> [ARP and NDISC]
> - both can be handled in more natural way.
> -- You will not need to mangle those packets when
>     sending/receiving.

This is also true if we introduce a function pointer. My last 
implementation does not mangle packets in the driver.

> -- You do not need to inspect ARP/NDISC packet.
>     By using netevent notification mechanism, you can
>     learn peer parameters.

That is worth to investigate. Will I get notifications when a ARP/NDISC 
will be send or only if the stack received ARP/NDISC packets? However, I 
can't see how this will help to get the firewire specific information 
into the ARP/NDISC packet. This has to be done either via the suggested 
function pointer or your extension of the mac address.

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

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

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

On Jan 20 Stephan Gatzka wrote:
> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
> 
> > My current position is to change "mac address" to
> >
> > struct fwnet_hwaddr {
> > 	u8	guid[8];
> > 	u8	max_rec;
> > 	u8	sspd;
> > 	u8	fifo[6];
> > };
> >
> 
> That is something I'm not really convinced of. As Stefan Richter pointed 
> out clearly, the fifo address might be different between IPv4 and IPv6 
> communication.

If it is of any help, the initial implementation could assume that IPv4
unicast_FIFO and IPv6 unicast_FIFO are the same.  RFC 3146 is silent on
this topic (which means it can be one way or the other), but from an
implementation point of view, using one FIFO offset for both seems quite
natural.  Currently the only existing RFC 3146 implementation which is
known to us is Mac OS X, and since your tests with OS X 10.6 went well,
they obviously use one offset for both protocols.

But if we actually put this assumption into the implementation now, we
should make sure that we can easily expand the implementation later in the
event that a third implementation comes across which uses separate
unicast_FIFOs.
-- 
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

On Jan 21 Stephan Gatzka wrote:
> On Jan 20 Waskiewicz Jr, Peter P wrote:
> > I'm no expert on firewire requirements, but if you go down the path
> > of adding a net_device_ops member, I'd recommend adding a pointer
> > to your own struct of ops.  This would be similar to wireless ops.
> >
> > Only a suggestion, since you may still need to add more ops later
> > on, and this way you can contain the inflation to a firewire-specific
> > struct of function pointers.
> >
> 
> Thanks for your note. Right now I only need on function pointer for 
> filling RFC3146 information and I can imagine doing the same for 
> IPv4/ARP which would be a second function.

There is a limited count of IEEE 1394 specifics:

  a) RFC 2734 ARP:  currently implemented by inspecting and mangling ARP
     packets within the firewire-net driver (inbound as well as outbound
     packets).

  b) RFC 2734 MCAP (Multicast Channel Allocation Protocol):  currently not
     implemented; not sure if needed (I see a few big downsides to using
     per-multicast-group channels); not sure if networking core support
     would be needed for this

  c) RFC 2855 DHCP for IEEE 1394:  currently not implemented; not sure if
     needed; not sure if it would concern the kernel at all

  d) RFC 3146 NDISC (Neighbor Discovery Protocol for IPv6):  That's the
     only real problem in search of a solution.

I bet there won't be any additional RFCs invented for networking over
1394, ever.
-- 
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

(2013年01月21日 16:39), Stefan Richter wrote:
> 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.)
> 

Sending multicast without MCAP is okay,
but receiving multicast without MCAP is broken.
We have to be able to listen to NS (DAD) on separate
channel which is been negotiated over MCAP, for example.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:

>> And, firewire driver does not seem to support zerocopy
>> (fragmented skb) support.  It help performance.
> 
> O.k., good point. I will have a look into that. But I suggest to not mix up this issue with the IPv6 over firewire enhancement. That should be a separate patch.

I agree, but do we have to two fifos? for what?
If it is for performance, zerocopy should help.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stefan Richter wrote:
> On Jan 20 Stephan Gatzka wrote:
>> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
>>
>>> My current position is to change "mac address" to
>>>
>>> struct fwnet_hwaddr {
>>> 	u8	guid[8];
>>> 	u8	max_rec;
>>> 	u8	sspd;
>>> 	u8	fifo[6];
>>> };
>>>
>>
>> That is something I'm not really convinced of. As Stefan Richter pointed 
>> out clearly, the fifo address might be different between IPv4 and IPv6 
>> communication.
> 
> If it is of any help, the initial implementation could assume that IPv4
> unicast_FIFO and IPv6 unicast_FIFO are the same.  RFC 3146 is silent on
> this topic (which means it can be one way or the other), but from an
> implementation point of view, using one FIFO offset for both seems quite
> natural.  Currently the only existing RFC 3146 implementation which is
> known to us is Mac OS X, and since your tests with OS X 10.6 went well,
> they obviously use one offset for both protocols.
> 
> But if we actually put this assumption into the implementation now, we
> should make sure that we can easily expand the implementation later in the
> event that a third implementation comes across which uses separate
> unicast_FIFOs.

Well, FIFO for which side?

I do believe sender will not (or say, must not) care if they use
different FIFO for both protocol or not.

Assume that peer has FIFO per protocol, one for IPv4 and another for
IPv6.  ARP advertise FIFO for IPv4 and NDP advertise FIFO for IPv6.
neighbour subsystem has protocol dependent tables, and two different
NCEs (neighbour cache entries) will be created.  So, sender will
correctly get FIFO from NCE for each protocol.


------------------------------------------------------------------------------
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

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
>> [ARP and NDISC]
>> - both can be handled in more natural way.
>> -- You will not need to mangle those packets when
>>     sending/receiving.
> 
> This is also true if we introduce a function pointer. My last implementation does not mangle packets in the driver.
> 
>> -- You do not need to inspect ARP/NDISC packet.
>>     By using netevent notification mechanism, you can
>>     learn peer parameters.
> 
> That is worth to investigate. Will I get notifications when a ARP/NDISC will be send or only if the stack received ARP/NDISC packets? However, I can't see how this will help to get the firewire specific information into the ARP/NDISC packet. This has to be done either via the suggested function pointer or your extension of the mac address.

Netevent example: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:netevent_cb().
It will be notified when NCE has been updated (by ARP/NDP, in most cases).

Yes, it is for learning Uniq-ID and FIFO from peer.

To send our Uniq-ID and FIFO to peer via ARP/NDP, I am proposing to use
extended MAC.  This will also help MCAP implementation, without big change
in IPv4/IPv6 or even whole net stack.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stefan Richter wrote:

>   b) RFC 2734 MCAP (Multicast Channel Allocation Protocol):  currently not
>      implemented; not sure if needed (I see a few big downsides to using
>      per-multicast-group channels); not sure if networking core support
>      would be needed for this

It is definitely needed because we need to listen on multicast group
for NDP, which might have already had its own channel.

MCAP sends "multicast group address", which is whole IP address.
In IP stack we only manages listening groups by special
"link-layer address" mapped by device specific transform function.
See net/ipv6/ndiscc:ndisc_mc_map() for IPv6.

I am proposing to extend MAC address to 16 bytes long so that we can
"map" whole IPv6 address into the "MAC".

On tx on fwnet, it can determine if the destination is multicast or not
by either by
- Checking protocol, and looking into protocol dependent multicast
  range
or
- Checking "EUI-64" group bit (here, we assume all node do not set it
  in its unique Id, and we map IPv6 multicast and IPv4 multicast in
  special way; e.g.
     ff00::/8  (which has "multicast bit" set)
     0100::/96 (which is also "multicast bit" set)

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

On Jan 21 YOSHIFUJI Hideaki wrote:
> Stefan Richter wrote:
> > On Jan 20 Stephan Gatzka wrote:
> >> On 01/20/2013 07:47 PM, YOSHIFUJI Hideaki wrote:
> >>
> >>> My current position is to change "mac address" to
> >>>
> >>> struct fwnet_hwaddr {
> >>> 	u8	guid[8];
> >>> 	u8	max_rec;
> >>> 	u8	sspd;
> >>> 	u8	fifo[6];
> >>> };
> >>>
> >>
> >> That is something I'm not really convinced of. As Stefan Richter pointed 
> >> out clearly, the fifo address might be different between IPv4 and IPv6 
> >> communication.
> > 
> > If it is of any help, the initial implementation could assume that IPv4
> > unicast_FIFO and IPv6 unicast_FIFO are the same.  RFC 3146 is silent on
> > this topic (which means it can be one way or the other), but from an
> > implementation point of view, using one FIFO offset for both seems quite
> > natural.  Currently the only existing RFC 3146 implementation which is
> > known to us is Mac OS X, and since your tests with OS X 10.6 went well,
> > they obviously use one offset for both protocols.
> > 
> > But if we actually put this assumption into the implementation now, we
> > should make sure that we can easily expand the implementation later in the
> > event that a third implementation comes across which uses separate
> > unicast_FIFOs.
> 
> Well, FIFO for which side?

Our Linux implementation should expose a single unicast_FIFO for
reception of both protocols, just in case that another implementation
expects just this.

For transmission, we should be ready to keep an IP-peer-to-1394-node
mapping with per-protocol unicast_FIFOs, but in my mind it is doubtful
that any such implementation exists (hence we could just stand prepared
to implement it later when proven to be needed -- if this simplifies the
initial implementation notably).

> I do believe sender will not (or say, must not) care if they use
> different FIFO for both protocol or not.
> 
> Assume that peer has FIFO per protocol, one for IPv4 and another for
> IPv6.  ARP advertise FIFO for IPv4 and NDP advertise FIFO for IPv6.
> neighbour subsystem has protocol dependent tables, and two different
> NCEs (neighbour cache entries) will be created.  So, sender will
> correctly get FIFO from NCE for each protocol.

OK.
-- 
Stefan Richter
-=====-===-= ---= =-=-=
http://arcgraph.de/sr/

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

YOSHIFUJI Hideaki wrote:
> Stefan Richter wrote:
> 
>>   b) RFC 2734 MCAP (Multicast Channel Allocation Protocol):  currently not
>>      implemented; not sure if needed (I see a few big downsides to using
>>      per-multicast-group channels); not sure if networking core support
>>      would be needed for this
> 
> It is definitely needed because we need to listen on multicast group
> for NDP, which might have already had its own channel.

Sorry, this was unclear and incorrect.  RFC3146 Section 9
(IPv6 Multicast) says that packets for all-nodes/all-routers/
solicited-node multicast addresses must be sent via broadcast
channel.  So, NDP should work without MCAP.

But, even so, I do not want to have broken implementation without
MCAP, or at least, we need prepare to support full multicast.
I do NOT want to have patchy implementation just for NDISC.

With extended MAC, networking core (including IPv4/IPv6) does not
need to be changed very much for supporting MCAP; no new hooks,
no new callbacks.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

> 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.

Full ack. And that's the reason why I feel very uncomfortable with a 
Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.

This seems possible with a single netdevice for IPv4/6 only if we 
_always_ use the same fifo address for both IPv4 and IPv6. Do we all 
agree on that?

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> 
>> 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.
> 
> Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
> 
> This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?

I do not understand what "that" and "this" mean here.
Do you want to have different FIFO on single net_device? If yes, for what?

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

>> Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
>>
>> This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
>
> I do not understand what "that" and "this" mean here.
> Do you want to have different FIFO on single net_device? If yes, for what?
>

Oh, I'm sorry for being mixed-up. I meant that your proposal for 
enhancing the hardware address seems to be a feasible solution, if we 
_never_ want to have distinct fifo addresses for IPv4 and IPv6. This 
will be just impossible with a single netdevice.

But I have to admit that I have no good use case for different fifo 
addresses...

So overall, your proposal seems to be a possible solution. Nevertheless, 
I can't help that I find it a bit awkward to have speed, max_rec and 
fifo address in the hardware address of the network device. For me, 
that's just the GUID.

I want to have an ack from Stefan Richter before I'm going to implement 
your solution.

Regards,

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

On Jan 21 Stephan Gatzka wrote:
> 
> >> Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
> >>
> >> This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
> >
> > I do not understand what "that" and "this" mean here.
> > Do you want to have different FIFO on single net_device? If yes, for what?
> >
> 
> Oh, I'm sorry for being mixed-up. I meant that your proposal for 
> enhancing the hardware address seems to be a feasible solution, if we 
> _never_ want to have distinct fifo addresses for IPv4 and IPv6. This 
> will be just impossible with a single netdevice.
> 
> But I have to admit that I have no good use case for different fifo 
> addresses...
> 
> So overall, your proposal seems to be a possible solution. Nevertheless, 
> I can't help that I find it a bit awkward to have speed, max_rec and 
> fifo address in the hardware address of the network device. For me, 
> that's just the GUID.
> 
> I want to have an ack from Stefan Richter before I'm going to implement 
> your solution.

Sorry for my delayed response.

I am not a contributor to net/, hence don't have a say over how the
networking APIs should evolve.

Any solution is fine with me, as long as net/ does not use any definitions
or declarations from <linux/firewire.h>.
-- 
Stefan Richter
-=====-===-= ---= ==-==
http://arcgraph.de/sr/

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

>
> I am not a contributor to net/, hence don't have a say over how the
> networking APIs should evolve.
>
> Any solution is fine with me, as long as net/ does not use any definitions
> or declarations from <linux/firewire.h>.

O.k. then I will go for Yoshifujis "extended hwaddress" approch.

I think I will divide all the stuff into two major pieces:

First I will rewrite the existing IPv4 over Firewire driver to use the 
notification mechanisms and also generate the RFC2734 ARP packets in the 
arp code.

Then I'll implement the IPv6 stuff based on that IPv4 solution.

Regards and many thanks for the discussion especially to Yoshifuji.

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stephan Gatzka]

> Then I'll implement the IPv6 stuff based on that IPv4 solution.
>
> Regards and many thanks for the discussion especially to Yoshifuji.
>

One last question: shall I use net or net-next?

Stephan

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> 
>> Then I'll implement the IPv6 stuff based on that IPv4 solution.
>>
>> Regards and many thanks for the discussion especially to Yoshifuji.
>>
> 
> One last question: shall I use net or net-next?

net-next, please.

--yoshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:

>> I am not a contributor to net/, hence don't have a say over how the
>> networking APIs should evolve.
>>
>> Any solution is fine with me, as long as net/ does not use any definitions
>> or declarations from <linux/firewire.h>.
> 
> O.k. then I will go for Yoshifujis "extended hwaddress" approch.
> 
> I think I will divide all the stuff into two major pieces:
> 
> First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
> 
> Then I'll implement the IPv6 stuff based on that IPv4 solution.

I even think that we do not need to have event notification if we
can just use max_rec, sspd and fifo embedded in the destination
"MAC address" in the sending packet.

--yosshfuji

Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information

[Stefan Richter]

On Jan 28 YOSHIFUJI Hideaki wrote:
> Stephan Gatzka wrote:
> 
> >> I am not a contributor to net/, hence don't have a say over how the
> >> networking APIs should evolve.
> >>
> >> Any solution is fine with me, as long as net/ does not use any definitions
> >> or declarations from <linux/firewire.h>.
> > 
> > O.k. then I will go for Yoshifujis "extended hwaddress" approch.
> > 
> > I think I will divide all the stuff into two major pieces:
> > 
> > First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
> > 
> > Then I'll implement the IPv6 stuff based on that IPv4 solution.
> 
> I even think that we do not need to have event notification if we
> can just use max_rec, sspd and fifo embedded in the destination
> "MAC address" in the sending packet.

Yes and no.  After a bus topology change, it takes a brief period for
firewire-core to have the new node(s) scanned and tell firewire-net about
them, so that firewire-net can add (or remove) items in the list for the
mapping between GUID on one hand and card:generation:nodeID on the other
hand.

So, right after a bus reset, we may already receive IP packets from nodes
which firewire-core didn't process yet.  But I guess this short period
isn't really a problem.

By the way, I wouldn't trust max_rec and sspd from 1394-ARP or 1394-NDP
packets.  These should rather be taken from firewire-core's bus analysis
as soon as this is complete.  Only unicast_FIFO can alas not be obtained
by bus analysis.  (IEEE 1394 addendum B:2002 made things more complicated
with regard to maximum payload and maximum transmission speed then they
were until addendum A:2000, in ways that the authors of RFC 2374 and 3146
surely could not anticipate.)
-- 
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d