Re: [PATCH v2] RDMA/CMA: fix iWARP adapter TCP port space usage

[Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html