Jason Gunthorpe wrote:
On Wed, Jun 23, 2010 at 01:46:47PM -0500, Steve Wise wrote:
Yes. Perusing the drivers/scsi/cxgb3i code I see the iscsi ipaddr is
actually stored in the port_info struct which is hung of the netdev_priv
of the cxgb3 device. It is set by cxgb3i_host_set_param() which is part
of the iscsi transport interface.
I wonder how does neighbor discovery, routing, etc work with iscsi?
For cxgb3i:
ND is handled by initiating ND via exported kernel services
(neigh_event_send()) and registering for NETEVENT_NEIGH_UPDATE net
events to get updated neigh entries.
The host routing table is consulted via ip_route_output_flow() to map a
destination ip address to a local netdev, and then if that device is T3,
it will do the iscsi offload.
I just think the customer looses when we add iwarp-specific tools,
ipaddrs, subnets, etc etc. And what about software iwarp? Will it use
the host stack tools and not these new tools? So then we end up with 2
sets of tools for iwarp devices. :(
Well, maybe you can get netdev to agree on some way to create an
interface that has all the IP services, but no TCP protocol binding?
Then the configuration could be largely the same. If you could share
that with the iscsi world then maybe it isn't so bad?
Maybe. I fear this will meet the same resistance from the netdev folks.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
