Roland Dreier wrote:
> Roland, do you think the iSCSI approach is a "good design" for iWARP
> devices?
Well, it's a different problem since as I said the port collision
problem is a non-issue for iSCSI anyway. But yes having a separate
interface to assign an iWARP IP address to an RNIC does seem to avoid
the immediate problem.
I actually don't know what the right answer is -- having a separate IP
address for iWARP does seem to lead to having to duplicate everything
for configuring it. (And this is the approach for the cxgb[34] iSCSI
drivers, right?)
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 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. :(
On the other hand trying to hook offloaded iWARP into the normal stack
does seem to lead to a mess. I see DaveM's point: TCP port space is
just the beginning -- filtering, queueing, etc also have config that
ultimately an offload device would want to hook too.
Maybe the sanest out of a bad set of options would be to come up with a
standard way to configure independent TCP/IP stacks that share a link.
really, dunno.
- R.
--
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
