> 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. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
