Mike Christie wrote:
> Maybe that is where I am missing your point. One of the reasons for this
> is to tell the kernel to ignore the routing rules and use the port we
> want. So I was saying if there is no a API to do this then just add one
> like someone did for tcp and the socket code.

bind-to-device like interface doesn't exist in the rdma-cm api which is based 
now only on IP, however, as I wrote, once you know a source ip, it is possible 
to bypass the routing rules by call rdma_bind on this ip or providing it as the 
source address in rdma_resolve_addr. With this at hand, I don't think I want to 
add new interface to the rdma-cm now.

>> I understand using IP is a bit problematic when DHCP is used for the
>> initiator, let me think about that a bit, thanks

> How about this, We can add a:
> ISCSI_UEVENT_TRANSPORT_EP_CONNECT_THROUGH_SRC = UEVENT_BASE + 20
> And for that we can pass the src addr after the dest addr like how you wanted

yes, basically, I think this is the way / route (...) I want to go through. The 
down 
side is this touching three pieces of the code (user-space, kernel transport, 
and iser), but I don't think we have much (any) other choices.

 
> For userspace, I think it is wrong to make the user interface based on
> the kernel API. If we used something like the name you see in ifconfig
> (ibX is the default for most drivers I think) then users can set the
> iface.net_ifacename to it. iscsid can just loop over the interfaces and
> match ibX with the ip and pass that down. The loop would be pretty much
> the same as in get_hwaddress_from_netdev() where we loop over the
> interfaces but it would do

If we are going on proving a source IP to the kernel then why go through 
the code that loops on interfaces? is this b/c today the semantics of s 
iface.ipaddress is "set this address to the net device associated with iscsi 
offload"? such that you don't want to create confusion/complexity? if this is 
the case, and you want the iser users to specify netdevice name such that user 
space translates it to source ip, then 
the code below has to be someone more involved:

> 
> transport.c:
> 
> iser_transport {
>     .ep_connect = iser_ep_connect;
> };
> 
> somewhere.c:
> getifaddrs()
> 
> for (ifa = ifap; ifa; ifa = ifa->ifa_next) {
> 
>     iser_ep_connect()
>         if (!strcmp(ifa->ifa_name, match_name))
>             ktransport_ep_connect(.... ifa->ifa_addr);

here this comparison isn't sufficient as someone might put few IPs on the 
net-device
and we want to find one of them which is in the subnet of the target portal 
(sorry...)

Or.

> 
> 
> 
> netlink.c
> ktransport_ep_connect(.... , struct sockaddr *src_addr)
> {
>     if (srcaddr)
>         ec->type = ISCSI_UEVENT_TRANSPORT_EP_CONNECT_THROUGH_SRC
>     else if
>     else
> 
>     .....
> 
>     memcpy(setparam_buf + sizeof(*ev), dst_addr, addrlen)
>     if (srcaddr)
>         memcpy(setparam_buf + currlen, src_addr, src_addrlen)
> 
> }
> 
> For the userspace interface for the user we can do pretty much anything.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to