[openib-general] Re: [PATCH] CMA and iWARP

[Steve Wise]

> Because an iWARP device can encompass multiple Ethernet ports
> with the same mac address. 

At the same time?  How does a switch handle this?  

I'm not clear on your issue here and why my mac based approach breaks
it.  

Lets start with a concrete example:  

Lets say I have an rnic device.  It has 2 ports.  It has 1 mac address
per port.  Assume the driver for this device installs 2 netdevs, one for
each port, and there's one ipaddr on each netdev.   

Now, this rnic device will register with the openib core as _one_ openib
device with 2 ports.  

When the CMA attempts to resolve a route and/or bind to an interface, it
first consults the routing table.  Lets assume it finds one of the
netdev devices for this rnic.  It then needs to find the associated
openib device.  What is wrong with using the mac address found in the
netdev device and finding which openib device has that mac address?  Why
does that break things?

I'm still fuzzy on this issue (and most things ;)

Given my example above, tell me what delta to that example exposes the
design flow and helps me understand your issue.

Sorry if i'm being dumb... :-\

> If they do not have a different IP
> address then there is no reason for the consumer to understand
> that they are distinct physical ports.

> The starting point here is the socket model, where the consumer
> is not even aware of which Ethernet NIC they are using by
> default. We are disturbing that model by saying that you
> have to know which RDMA device so that memory can be registered.
> 
> We should not go more fine-grained than that.
> 
> Doing so is complicating the programming model, and interferes
> with existing port-failover solutions already deployed in the
> Ethernet space.

This doesn't have anything to do with the consumer/ULP programming
model, which is all based on ip addresses with the new cma module.  

We're really talking about the interface between the openib core, the
openib iwarp devices, and the linux netdev subsystem.